跨版本迁移失败主因是目标库sql_mode、字符集、TIMESTAMP/JSON语法不兼容；需修改sql_mode、显式指定utf8mb4_0900_ai_ci字符集、忽略时间戳默认值，并勾选Navicat中结构+数据、遇到错误继续、取消外键限制、转换为小写四项关键开关。

跨版本迁移 mysql 不能只靠点“开始”，invalid default value for 'xxx'、中文变问号、json 字段报错、表为空——这些不是 navicat 坏了，而是目标库的 sql_mode、字符集、时间戳语法在拦截不兼容语句。

为什么直接「数据传输」会失败？

Navicat 默认按源库规则生成 SQL，不会自动降级适配目标版本。MySQL 5.7 和 8.0 在以下几处有硬性差异：

• TIMESTAMP 字段若默认值为 CURRENT_TIMESTAMP，8.0 严格模式下会报 Invalid default value
• 8.0 默认排序规则是 utf8mb4_0900_ai_ci，而旧导出常用 utf8mb4_general_ci，静默降级会导致索引失效
• JSON 字段在 5.7 是扩展类型，在 8.0 成为原生类型，但建表语句若含 JSON NOT NULL DEFAULT 'null' 类写法，8.0 会拒绝执行
• Linux 下 8.0 默认大小写敏感，若源库表名混用大小写（如 UserLog 和 userlog），不处理会触发 Table doesn't exist

迁移前必须改的三项目标库配置

这三步跳过任意一项，迁移大概率卡在中途或留下隐患：

• 执行 SET GLOBAL sql_mode = 'STRICT_TRANS_TABLES,NO_ZERO_DATE,NO_ZERO_IN_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION';，再查 SELECT @@sql_mode; 确认生效
• 目标库建库时显式指定：CREATE DATABASE your_db CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;
• 如果源库有 TIMESTAMP 字段带默认值，必须在 Navicat「数据传输」→「高级」中勾选「忽略时间戳默认值」

Navicat「数据传输」里最关键的四个开关

这些选项不是可选，而是跨版本能否跑通的决定性设置：

Mysql Skill 1.0.0 (3)

MySQL 数据库管理技能，能够通过自然语言查询和管理数据库，支持 SELECT/INSERT/UPDATE/DELETE、表管理、备份恢复等操作。当用户提及 MySQL、数据库查询、建表或数据备份时使用此技能。

下载

• 「结构 + 数据」：必须同时勾选；仅传数据会导致目标表不存在，报错 Table 'xxx' doesn't exist
• 「遇到错误继续」：务必开启——个别字段（如 ENUM 值超长）失败时，关闭则整个任务中断
• 「外键限制」：迁移中建议取消勾选，等全部导入完成后再手动执行 ALTER TABLE ... ADD CONSTRAINT，避免依赖顺序错乱
• 「转换对象名为小写」：Linux 环境下必须勾选，防止大小写混用导致表找不到

迁移后必须做的四件事，不是“完成”就完事

Navicat 显示“完成”只是文件传完了，不代表数据可用：

• 立刻连目标库执行：SELECT COUNT(*) FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'your_db';，核对表数量是否一致
• 抽样比对关键表的 MD5(CAST(... AS CHAR)) 或行数，确认无截断（尤其含中文、emoji 的字段）
• 执行 SHOW CREATE TABLE xxx;，检查字段类型、默认值、排序规则是否与源库一致
• 验证字段排序规则是否仍是 utf8mb4_0900_ai_ci，而非被降级成 utf8mb4_general_ci（后者在 8.0 中性能差、索引可能失效）

最常被跳过的其实是排序规则校验——它不报错，但后续 LIKE 查询变慢、中文检索不准，问题要等上线后才暴露。