记录一个mysql数据迁移的坑
踩坑说明：
数据迁移后，校验数据是否完全迁移时，发现使用table_rows查询出的数据量与源数据库不一致。
测试背景：
某个老系统需要迁移到阿里云，数据9G+，需要模拟数据迁移
测试方案：
MYSQL导入导出测试，使用测试环境数据库作为原始库（11341917数据），停止对应的后台服务，确认数据量不变的情况下，使用不同的方式进行导出导入进行对比；
每一种测试方案使用独立的数据库，相互不影响
一、使用navicat12进行导入导出
1. windows11家庭版，navicat12, mysql5.7，导入2G+的SQL时报错，测试1.9G大小的SQL可正常导入。
2. 使用navicat的命令行工具，执行source，报错
3. 使用mysql 5.7 command line client可以导入navicat12导出的SQL，耗时超过 2 小时
3.1 通过查看源数据库的数据量，然后DROP目标库，导入过程中，实时统计数据量来估算导入的进度
USE information_schema; SELECT sum( table_rows ) FROM TABLES WHERE TABLE_SCHEMA = 'database_name'
二、使用dump
# 使用cmd mysqldump.exe -uroot -pdatabase_name > e:\xxxx.sql mysqldump -h 192.168.1.110 -P 3306 -u root -p database_name > e:\xxxx.sql # 使用mysql comman client use database_name; source E:/xxxx.sql
三、对比
遇到的问题，同一原始库，使用不种方式分别导出，再导入时，数据条件与原始库不一致，以相同方式导出大小也有偏差
-- 数据库的总记录数
USE information_schema; SELECT sum( table_rows ) FROM TABLES WHERE TABLE_SCHEMA = 'database_name'
分别统计不同数据库中表的数据量，复制到excel中对比，将数量不同的表筛选出来，再使用select count(*) from table_name对比实际数量。
发现使用select count(*) 统计的数量是相同的，原因可能是不同的导出导入方式，更新TABLE_SCHEMA的方式不同
USE information_schema; SELECT table_name, table_rows FROM TABLES WHERE TABLE_SCHEMA = 'database_name' ORDER BY table_name ASC;
参考文档：
|
使用本地同一数据库进行对比
数据量：11341917/3103634KB
数据表：118；
|
navicat
(直接传输数据)
|
navicat(转储sql)
|
navicat(导出导入向导csv)
|
dump
|
|
远程导出（110）
|
9分10秒
（11470070条）
|
4分42秒/2.95G
|
15分18秒/2.35G/单表独立CSV
|
3分48秒/2.29G；
使用powershell遇到中文乱码，cmd正常
|
|
本地导入
|
-
|
超过2G，无法导入；
使用source命令导入需要2小时以上
|
18分18秒
（导入后11503452条）
|
11分06秒（导入后11056988条）
|
|
本地导出
（全部导出为SQL，比较大小）
|
3分22秒/
3103634KB
|
-
|
3分32秒/
3104592KB
|
3分16秒/
3103634KB
|
|
小结
|
方便快捷，适合局域网的环境使用
|
图形化界面，操作简单，可查看进度
|
图形化界面，操作简单，可查看进度；
能够以表为单位导出，可单表导入，也可多选CSV文件导入多表
|
需要cmd与mysql cmd，操作不方便，速度快；
可编写成批处理文件，一键备份；
|
