必须加--single-transaction和--master-data=2：前者通过REPEATABLE READ事务隔离保证InnoDB表一致性快照，后者以注释形式写入binlog位置用于复制起点；若启GTID还需--set-gtid-purged=OFF，导入前需禁用严格sql_mode并执行mysql_upgrade。
mysqldump 导出时必须加 --single-transaction 和 --master-data=2
不加这两个参数，导出的数据可能不一致或无法准确定位复制起点。尤其是 --single-transaction 能保证 InnoDB 表在导出期间看到一致快照；--master-data=2 会把当前 binlog 位置写进 SQL 文件开头（作为注释），方便后续追加增量。如果目标库启用了 GTID，还得额外加 --set-gtid-purged=OFF，否则导入时会报错 GTID_PURGED cannot be changed。
导入前要关掉 sql_mode 中的严格模式
MySQL 5.7 默认启用 STRICT_TRANS_TABLES 和 NO_ZERO_DATE，而 5.6 的很多表允许 0000-00-00 时间值或空字符串插入非空字段。直接导入会卡在第一张有问题的表上，报错类似：Incorrect date value: '0000-00-00' 或 Data truncated for column 'xxx'。临时解决方法是：
- 启动 MySQL 5.7 后，先执行
SET GLOBAL sql_mode=''; - 或者修改配置文件
/etc/my.cnf，在[mysqld]下加一行sql_mode=（留空） - 重启服务再导入，否则
source命令仍会触发校验
mysql_upgrade 不是可选步骤，而是必须立即执行
即使 SQL 文件导入成功，系统库（如 mysql、performance_schema）结构仍停留在 5.6 状态。不运行 mysql_upgrade -u root -p，会出现：
Table 'mysql.plugin' doesn't exist- 用户密码验证失败（
mysql.user表字段变更） -
SHOW PROCESSLIST报错或缺失列
注意：必须用 5.7 的 mysql_upgrade 工具，且要在导入数据后、业务切流前执行；它会自动重建系统表并更新权限结构。
字符集与排序规则差异容易被忽略
MySQL 5.8 默认给 utf8mb4 表加上 utf8mb4_0900_ai_ci 排序规则，但这个规则在 5.7 中不存在。如果你是从 5.8 备份再倒灌到 5.7（常见于测试环境误操作），导入会直接失败。实际从 5.6 迁移时也要留意：5.6 的 utf8mb4_general_ci 在 5.7 中虽可用，但建议在导出前统一改用 utf8mb4_unicode_ci——它兼容性更好，且避免后续升级到 8.0 时再处理。
真正麻烦的是那些没显式指定 COLLATE 的建表语句，5.7 会按 server 默认规则补全，而这个默认值可能和原库不一致。最稳妥的做法是在 mysqldump 里加 --skip-set-charset 并手动在 SQL 文件头加上 SET NAMES utf8mb4;，防止客户端连接层乱码。
