不能直接解决跨版本兼容问题，但能缓解部分语法差异；--compatible仅调整DDL语句格式（如去掉DEFINER、禁用ENGINE声明），不重写JSON函数或降级窗口函数，且不影响数据内容与字符集隐式转换问题。
mysqldump 导出时指定 --compatible 参数能解决跨版本兼容问题吗
不能直接解决，但能缓解部分语法差异。MySQL 5.7 和 8.0 之间存在默认 SQL 模式、保留字、JSON 函数等不兼容点，--compatible 只控制导出语句的“外观”，比如去掉 DEFINER、禁用 ENGINE=InnoDB 显式声明、避免使用 ROW_FORMAT 等，但它不会重写 JSON_EXTRACT() 或自动降级窗口函数。
实操建议：
- 导出 MySQL 8.0 库到 5.7 时，必须加
--compatible=mysql40或--compatible=ansi，否则可能含utf8mb4_0900_as_cs这类 8.0 特有排序规则 - 若目标库是 5.7，优先在源库执行
SET SESSION sql_mode='NO_ENGINE_SUBSTITUTION';再导出，比依赖--compatible更可靠 -
--compatible不影响数据内容，只改 DDL 语句格式；BLOB/TEXT 字段、时间戳精度丢失等问题需另作处理
导出大表时如何避免锁表和超时
默认 mysqldump 对 InnoDB 表加 SELECT ... FOR EXPORT（5.6+）或 FLUSH TABLES WITH READ LOCK（老版本），会阻塞写入。关键不是“要不要锁”，而是“用什么方式锁”。
实操建议：
- 强制启用一致性快照（推荐）：
mysqldump --single-transaction --skip-lock-tables—— 仅对 InnoDB 有效，不锁表，但要求事务隔离级别为REPEATABLE READ - 跳过统计信息收集（加速元数据获取）：
--skip-tables-list不适用，改用--no-tablespaces+--skip-triggers（若无需触发器） - 超时由客户端控制：
mysql --connect-timeout=30 --net-read-timeout=3600不影响mysqldump，应改用mysqldump --net-timeout=3600（注意这是 MySQL 8.0.22+ 新增参数） - 分表导出更可控：
mysqldump db_name table1 table2 > dump.sql，避免单文件过大导致恢复失败
导入时提示 ERROR 1231 (HY000): Variable 'sql_mode' can't be set to the value of 'NO_AUTO_CREATE_USER'
这是 MySQL 8.0 移除了 NO_AUTO_CREATE_USER 模式值，但 mysqldump 在 5.7 导出的文件里仍会写入该设置。导入到 8.0 时直接报错，且无法通过 --force 跳过。
实操建议：
- 导出时不写 sql_mode：加
--set-gtid-purged=OFF --skip-set-charset --no-defaults，并手动删掉 dump 文件头部的SET sql_mode行 - 导入前预处理 dump 文件：
sed -i '/^SET sql_mode/d' dump.sql
- 若用管道导入，可用
grep -v '^SET sql_mode' dump.sql | mysql -u root -p db_name - 更稳妥的做法：在目标 MySQL 8.0 上提前执行
SET GLOBAL sql_mode=(SELECT REPLACE(@@sql_mode,'NO_AUTO_CREATE_USER',''));，再导入
mysqldump 导出的 SQL 在目标库执行后主从不一致
常见于启用了 GTID 的环境。mysqldump 默认导出 SET @@GLOBAL.GTID_PURGED，如果目标从库已有其他事务，强行设置会清空已同步的 GTID 集合，导致后续复制中断或跳过事务。
实操建议：
- 从库导入前确认是否要保留原有复制位置：
--set-gtid-purged=OFF（最常用），或--set-gtid-purged=AUTO（仅当源库gtid_mode=ON且无未 purged 事务时安全） - 若目标是新从库，且需基于 dump 建立复制，应配合
--master-data=2（记录 binlog 位置）而非依赖 GTID - 导入后务必检查：
SHOW SLAVE STATUS\G中的Retrieved_Gtid_Set和Executed_Gtid_Set是否连续，不连续说明 GTID 被覆盖 -
--single-transaction和--set-gtid-purged组合使用时，GTID 设置发生在事务 START TRANSACTION 之后，顺序敏感，不可随意调换参数位置
utf8mb4_unicode_ci，dump 文件里没显式声明，目标库若默认 utf8mb4_0900_as_cs，导入后排序行为就变了。这不会报错，但业务查询结果可能异常。 
