Submitted by gouki on 2022, November 11, 12:40 PM
买了腾讯云的轻量数据库，便宜（其实现在和直接买1c1g的数据库也差不多了）。在做数据迁移的时候直接用了navicat的data transfer（这功能真方便）
因为数据库不大，只有2~300M，用datatransfer走起来非常快。基本上3分钟左右 就搞定了。如果我dump sql，再upload & import sql，反而比这个速度还要慢一点。
然后问题就来了，查询的时候，全是乱码，这个很明显，是latin1的问题了，于是上数据库 执行了一下：SHOW SESSION VARIABLES LIKE 'character\_set\_%';果然
character_set_client latin1
character_set_client_handshake ON
character_set_connection latin1
character_set_database utf8mb4
character_set_filesystem binary
character_set_results latin1
character_set_server utf8mb4
character_set_system utf8
这个就纠结了，即使我set names utf8mb4，用datatransfer也是这个问题。
我导数据过来的那一台，也是轻量级数据库，理论上不应该会有这个问题，于是我看一下connection的相关信息。发现正常的那台，encoding居然选的是auto，而这台不正常的选择的是utf-8，难道是因为这个原因？于是切回auto重连。
再次运行SHOW SESSION VARIABLES LIKE 'character\_set\_%';果然 character_set_client 已经恢复成utf8mb4了。
这个问题也真是妖~
DataBase | 评论:0
| 阅读:3033
Submitted by gouki on 2022, July 19, 2:45 PM
突然发现自己还有一个database的分类，想想以前还在为了折腾怎么弄mysql更好，后面被各种数据库折腾（小型公司，不涉及大数据库，都是常规的，象pg/sqlite/sqlserver/mongodb/redis）。
平时用的最多的还是navicat，不过我现在还在用11，用它的原因很的很奇怪也很尴尬
1、他的 cmd+ . , cmd+shift+.可以用来关库关表 （12开始，居然没有这个快捷键了）
2、12开始密码存到keychain里了。导致我其实没有办法迁移数据库（确实很尴尬，很多密码居然都忘光了。。。。但还能连接）
3、UI的变化，也让我有点不太习惯。
所以只能一直用着11了，11也有不少小问题，比如从新版的macos 11起，在data管理界面，对数据操作的Icon全部不见了，我都是凭记忆在猜在操作。
所幸+，-等还在因定的位置，刷新可以cmd+R，所以我其实已经忍了好多年了。
之所以还在一直使用，就是因为navicat的data transfer实在太方便了。对于一些小的表，要复制到本地，或者复制到线上。。直接在表名上data transfer就可以导入到指定的target库里了。
当datagrip出来后，我本来想的是可以迁移了，至少他是免费的，而且也支持市面上几乎所有的数据库，然而就是我说的data transfer这个功能阻挡了我，即使我安装了datagrip，也很少用它，直接我无意中搜索到了这个：
Copy | DataGrip (jetbrains.com)，原来它不叫data transfer，而是叫：copy to ....,将指定的表copy 到target里。
简单的在本地用sqlite进行了测试，操作完美，但这毕竟只是同库操作，于是我又试了一下,copy table from sqlite to mysql，完美~~
看来以后可以切换着使用datagrip了~（缺点也有，打开的时候数据过多的时候，没有navicat快。想想也是，毕竟是基于java的。而人家是纯C写的（也可能objc） ）
结论：是的，你真的可以开始尝试DataGrip了
---EOF---
刚发现，DataGrip居然是收费的。不过我反正都买了全家桶了，所以也可以自豪的说用正版了，要知道原来用navicat premium可是擦边球的，You Know~~
DataBase | 评论:0
| 阅读:4562
Submitted by gouki on 2020, September 13, 11:47 PM
很突然，线上有一台服务器，突然报表不存在。所有的项目只要涉及到数据库的，都直接报表不存在。SSH到服务器上一看，进程也活着，目录下的文件也存在着，怎么就表不存在了呢？
当时也没有注意，觉得可能是程序出错了。就restart了一下数据库，结果，这回出大事了，数据库无法启动。再启动，仍然是这个问题。连忙看了一下日志，发现报错原因居然是磁盘满了。这，不科学啊。df -h 看一下，果然，系统盘自带的20G，剩余空间为0。
怎么办？先清一下apt-cache，发现多出100多M的空间，尝试启动了一下，果然数据库启动了。再检查到底是谁占了？直接du -sh /var/log。居然只有200M，那是怎么回事呢？
继续 找，du -sh 一个目录一个目录的看。发现居然是mail目录写满了，一个mail文件。17G，用tail -n 1000 看了一下。文件居然都来自crontab ，再打开crontab -l，才发现，原来是有一个5年前的svn的勾子在运行。这个勾子，每5秒一次，就这样辛苦的运行了5年，终于通过邮件，硬生生的将磁盘写满了。
知道问题所在就简单了。关闭crontab （因为已经不用了）。同时清空邮件文件。再df -h，发现多出17G空间。好嗨森
DataBase | 评论:0
| 阅读:6437
Submitted by gouki on 2020, March 31, 12:22 AM
习惯了用navicat之后。居然不会用命令行了。。。
记录一下算是备份
1、进入mysql命令行，创建一个新库，create database xxxx; //先看一下旧库的格式。用show create database `库名`，主要是看一下旧数据库的编码：
CREATE DATABASE `xxx` DEFAULT CHARACTER SET UTF8 COLLATE UTF8_GENERAL_CI;
2、mysqldump 旧库 -u root -p123456 --add-drop-table | mysql 新库 -u root -p123456
假设密码是123456
3、grant 权限给指定的用户
grant all privileges on xxx.* to 'user'@'localhost' identified by 'password'，很方便的指定。记得localhost那个地方尽量不要留空。留空默认代码的是%
4、真正要用的时候，其实查一查都OK。。
DataBase | 评论:0
| 阅读:7723
Submitted by gouki on 2017, September 21, 2:07 AM
原来的数据库是N年前的，默认字符集是latin1，但是有一些旧代码中，连接参数写的是UTF8，于是就这样。。。DB字符集为latin1，连接UTF8，存到数据库也是UTF8，wj但查看的时候显示是???
为了标准统一，于是使用mysqldump -uxx -p database a b c d e > dump.sql，将部分表先导出来
然后修改导出sql的charset=latin1;改为charset=utf8;
至此，操作完成。简单粗暴
-------EOF--
deeka说，如果有200G呢。目前我是停机处理的。因为要处理的数据也不是很多。如果不是因为升级换库的时候出现不能访问我也不会这么做。
但好象也没有特别好的方案。因为直接alter的时候也是各种不正常。才dump的
DataBase | 评论:1
| 阅读:17116
