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的读取权限，需要单独授予。 

参考：

《乱码的前世今生 —— 字符集和比较规则》