应使用--compatible=mysql57导出sql文件，该参数可自动将utf8mb4_0900_ai_ci等8.0新增排序规则降级为5.7兼容的utf8mb4_general_ci，并规避语法不兼容问题。
不能直接导入，大概率会报错或静默丢数据。MySQL 8.0 和 5.7 在字符集、排序规则、SQL 模式、时间类型默认值等关键点上存在硬性不兼容，不是加个参数就能绕过去的。
遇到 Unknown collation: 'utf8mb4_0900_ai_ci' 怎么办
这是最常卡住恢复流程的错误，本质是目标库（比如 MySQL 5.7）根本不认识 8.0 新增的排序规则名。
- 别用文本编辑器全局搜替
utf8mb4_0900_ai_ci→ 容易误改字段内容里的字符串，导致数据损坏 - 临时验证可用：手动把备份文件里所有
COLLATE=utf8mb4_0900_ai_ci替换为COLLATE=utf8mb4_general_ci，但仅限测试环境 - 生产推荐做法：在目标库提前执行
ALTER DATABASE db_name CHARACTER SET = utf8mb4 COLLATE = utf8mb4_general_ci;，再导入 - 更稳妥的源头控制：导出时就用
--compatible=mysql57，它会自动降级排序规则输出
ERROR 1067 (42000): Invalid default value for 'created_at' 的根因与处理
这个错说明你正在往 8.0 导入一个含 created_at DATETIME DEFAULT '0000-00-00 00:00:00' 的表，而 8.0 默认启用严格模式，拒绝非法日期。
- 5.7 备份里常见这种写法，8.0 直接报错；反过来，8.0 备份里带
STORED GENERATED COLUMN，5.7 会直接语法报错 - 导出时加
--skip-tz-utc --no-defaults可减少时间类字段干扰，但治标不治本 - 真正要解决，得在导出端就模拟目标版本行为：哪怕你在 8.0 上执行
mysqldump，也必须加--compatible=mysql57 - 如果已拿到问题备份文件，可用
sed -i "s/DEFAULT '0000-00-00 00:00:00'/DEFAULT CURRENT_TIMESTAMP/g" backup.sql批量修正（注意先备份原文件）
为什么 --compatible=mysql57 必须加，且不能只靠 --set-gtid-purged=OFF
--set-gtid-purged=OFF 只解决 GTID 元信息冲突，对语法、字符集、排序规则、默认值这些底层不兼容完全无效。
-
--compatible=mysql57强制mysqldump输出符合 5.7 语义的 SQL：比如用utf8mb4_general_ci替代新排序规则，去掉ROW_FORMAT=COMPACT等 8.0 特有选项 - 必须显式指定
--default-character-set=utf8mb4，否则依赖服务端默认值，不同版本可能 fallback 到utf8导致乱码 - 不要信“跳过校验能恢复”，
--force参数会让错误静默跳过，比如字段截断、JSON 解析失败，数据已丢你还不知道
版本不兼容不是配置开关能调平的，核心矛盾在于 SQL 语义和存储格式的断裂。最容易被忽略的是：即使你用 8.0 导出并加了 --compatible，如果目标库没提前执行 ALTER DATABASE ... COLLATE=...，导入后新插入的数据仍可能用错排序规则，查不出结果或排序异常——这比恢复失败更难排查。
