MySQL 导出导入的101个坑
最近接到一个业务自行运维的MySQL库迁移至标准化环境的需求，库不大，迁移方式也很简单，由开发用myqldump导出数据、DBA导入，但迁移过程坎坷十足，记录一下遇到的各项报错及后续迁移注意事项。
一、 概要
- 空间问题
- 源与目标库版本
- 脚本乱码（尤其是跨平台传输后）
- MySQL远程表
- DEFINER问题
- 字符集与排序规则
- 导入命令
- 权限问题
二、 问题详情
1. 空间问题
确保目标库空间不小于源库，尤其是在进行了多轮导入测试后，会生成大量binlog，可能导致空间不足，报错 The table xxx is full。
2. 源与目标库版本
一般来说要求源与目标库版本一致，若不一致需业务提前验证兼容性，避免迁移后连接报错。
迁移后应用启动报错 Could not retrieve transation read-only status server，查询资料发现与目标库版本有关：MySQL数据库服务为8.0.22，而在项目开发的过程中使用了低版本的MySQL驱动包
Could not retrieve transation read-only status server 的解决办法-CSDN博客
3. 脚本乱码
主要是Windows与Linux互传文件时，换行符可能被识别为乱码，需要替换处理
Linux、Windows、Mac换行符相互转换方法_windows换行符转linux-CSDN博客
4. MySQL远程表
导入后发现两张表数据为空，查看定义发现为MySQL远程表，需修改表定义语句
CONNECTION='mysql://目标库用户名:密码@ip:端口/目标库名/目标表名'
5. DEFINER问题
源端导出的视图、存储过程等可能带有DEFINER信息。若目标库不存在对应用户，会导致创建及查询报错。
导入报错
查询报错
可能直接报 Access denied for user test_read@'%'，也可能报
查看DEFINER设置
cat pexetech.sql |grep DEFINER
替换为目标库DEFINER
sed -i 's/`root`@`%`/`app_rw`@`10.%`/g' pexetech.sql
6. 字符集与排序规则
导入报错
源库
目标库
由于utf8与utf8mb4对应字符长度不同，导致导入时报错字段太长。若为其他不兼容字符集，还可能导致乱码。
解决方法：使用与源库相同的字符集与排序规则。在本例中由于导出语句自带了字符集及排序规则，DBA不进行初始DB创建，直接使用脚本导入即可。
7. 导入命令
建议使用 mysql -uroot -p < pexetech.sql 方式，报错时可自动停止并显示报错语句
不建议使用 source pexetech.sql，在导入语句过多时会快速刷屏，且不会显示报错语句
8. 权限问题
确认目标库业务账号除标准权限外是否还需额外权限，避免报错。
例如本例中业务用户除标准权限外，应用还需要mysql.help_topic的读取权限，需要单独授予。
参考：
《乱码的前世今生 —— 字符集和比较规则》