Navicat结构同步不自动适配MySQL 5.7/8.0语法差异，需手动确认兼容性：源库5.7与目标库8.0混用时，Navicat可能生成含双引号DEFAULT、INVISIBLE INDEX、ALGORITHM=INSTANT或GENERATED COLUMN等不兼容语句；其比对忽略分区、隐藏索引、生成列等元数据，且ALTER语句（如MODIFY COLUMN）易引发类型截断或ENUM顺序错乱，执行前须人工核验SHOW CREATE TABLE、替换为CHANGE COLUMN、删除高危关键字并补全分号。
Navicat结构同步不自动适配MySQL 5.7/8.0语法差异
Navicat不会根据源库和目标库的MySQL版本自动调整生成的SQL语义。比如源库是MySQL 5.7，建表用了DEFAULT '2023-01-01'（单引号），目标库是MySQL 8.0时，Navicat仍可能生成带双引号的DEFAULT "2023-01-01"——这在8.0中虽可执行，但若字段类型是DATE且sql_mode含STRICT_TRANS_TABLES，会因引号解析差异触发隐式转换警告甚至失败。
更关键的是：MySQL 8.0新增的字段属性（如STORED GENERATED COLUMN、INVISIBLE INDEX）在5.7中根本不存在。Navicat比对时若发现8.0库有这些特性，而5.7库没有，它默认会生成DROP COLUMN或ALTER TABLE ... DROP INDEX，而不是跳过或报错提示。
- 必须手动确认“对象选择”页中每张表的
GENERATION_EXPRESSION字段是否在两边都存在——查SHOW CREATE TABLE最稳 - 若目标库是5.7，看到预览SQL里出现
INVISIBLE关键字，立刻停手；该语句在5.7中直接报错ERROR 1064 - Navicat对
JSON字段的比对基于字符串长度和默认值，不校验内部schema；5.7的JSON字段在8.0中可能被识别为json_valid()不通过，但Navicat不会标出
分区定义、隐藏索引、生成列必须人工核对
Navicat结构同步逻辑只读取INFORMATION_SCHEMA.TABLES和COLUMNS，而MySQL 8.0的分区元数据存在PARTITIONS视图，隐藏索引信息在STATISTICS视图中标记INDEX_COMMENT = 'invisible'，生成列定义则藏在COLUMNS.GENERATION_EXPRESSION里——这些全被Navicat忽略。
结果就是：源库是PARTITION BY RANGE (id)，目标库是普通表，Navicat仍显示“0 difference”；或者8.0库中一个INVISIBLE INDEX idx_status在5.7库中根本不存在，Navicat也不会提示缺失。
- 比对前逐表执行：
SELECT PARTITION_NAME, PARTITION_METHOD FROM INFORMATION_SCHEMA.PARTITIONS WHERE TABLE_SCHEMA = 'db' AND TABLE_NAME = 't'，两边都返回空才安全 - 检查隐藏索引：
SELECT INDEX_NAME, INDEX_COMMENT FROM INFORMATION_SCHEMA.STATISTICS WHERE TABLE_SCHEMA = 'db' AND TABLE_NAME = 't' AND INDEX_COMMENT = 'invisible' - 生成列确认：
SELECT COLUMN_NAME, GENERATION_EXPRESSION FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_SCHEMA = 'db' AND TABLE_NAME = 't' AND EXTRA LIKE '%VIRTUAL%'
SQL预览页里的ALTER语句可能语义错误
Navicat生成的ALTER TABLE ... MODIFY COLUMN在跨版本场景下极易出问题。例如5.7中VARCHAR(255)升级到8.0后，因utf8mb4_0900_ai_ci排序规则导致索引长度超限，8.0实际建表可能是VARCHAR(191)。Navicat检测到长度变化，就生成MODIFY COLUMN name VARCHAR(191)——但它没考虑：这个变更在5.7目标库上执行会失败（5.7不认191这个截断逻辑）。
另一个典型是ENUM字段新增值。Navicat一律用MODIFY COLUMN status ENUM('a','b','c','d')重建，但5.7对ENUM值顺序敏感，若原值顺序是('a','c','b')，新语句会重排并丢失含义；8.0虽支持动态增删，但Navicat不调用ALTER TABLE ... CHANGE COLUMN ... ADD VALUE语法。
- 预览SQL中凡出现
MODIFY COLUMN，先查源库SHOW CREATE TABLE确认原始定义，再比对目标库当前字段类型是否真不一致 - 看到
ENUM字段变更，一律替换为CHANGE COLUMN形式，并确保值列表顺序与源库完全一致 - 若目标库是5.7，预览里出现
ALGORITHM=INSTANT必须删除——5.7不支持该关键字，执行即报错
执行前必须验证三类SQL特征
Navicat导出的SQL文件默认无分号结尾，且常混入SET FOREIGN_KEY_CHECKS=0这类危险开关。跨版本同步时，这两点叠加会放大风险：比如在MySQL 5.7目标库执行8.0生成的SQL，因缺少分号导致多条语句被当做一个命令，CREATE TABLE后面紧跟INSERT直接报错；而FOREIGN_KEY_CHECKS=0又让外键约束失效，后续ALTER TABLE可能破坏关联完整性。
- 打开导出的SQL文件，全局搜索
;\n，补全所有缺失的分号（注意Windows换行是\r\n） - 删掉开头的
SET FOREIGN_KEY_CHECKS=0和结尾的SET FOREIGN_KEY_CHECKS=1，改用单条语句末尾加ALGORITHM=INPLACE控制锁级别 - 检查是否有
CREATE TABLE ... ENGINE=InnoDB ROW_FORMAT=DYNAMIC这类8.0默认参数——5.7虽支持，但若目标库innodb_file_format仍是Antelope，会静默降级为Compact，引发后续备份工具识别异常
真正麻烦的从来不是“能不能比”，而是“比出来的东西敢不敢直接跑”。Navicat给的只是差异快照，不是迁移方案。每个ALTER背后都得问一句：这个操作在目标版本里有没有副作用？有没有被隐式降级？有没有触发新的sql_mode限制？
