Navicat误拆复合主键根源在于其依赖SHOW CREATE TABLE解析主键时受输出格式干扰，如语句被截断、换行错位或含不可见字符，导致仅识别首字段；应通过information_schema验证真实主键结构、禁用易干扰选项，并人工校验补全SQL脚本。
Navicat结构同步误拆复合主键的根源在SHOW CREATE TABLE输出格式
navicat 不会“主动拆分”主键，它依赖 show create table 返回的建表语句解析主键结构。如果源库执行该命令后返回的语句里主键定义被截断、换行错位或含不可见字符（比如某些 mysql 客户端自动折叠长索引定义），navicat 就可能只识别出第一个字段，漏掉后续列。
常见诱因包括：MySQL 服务端 max_allowed_packet 过小导致长建表语句被截；使用了旧版 MySQL 客户端连接源库再导出 DDL；或建表时用多行写法但未对齐括号，例如：
CREATE TABLE orders ( order_id BIGINT, user_id INT, created_at DATETIME, PRIMARY KEY (order_id, user_id) );
这种换行写法在部分 Navicat 版本中会被误判为仅 order_id 是主键。
如何验证源库主键定义是否被 Navicat 正确读取
别信 Navicat 同步界面里显示的“差异预览”，它只是前端缓存渲染。真实依据永远是源库元数据本身。
- 在源库直接执行
SHOW CREATE TABLE `table_name`，复制完整输出，粘贴到文本编辑器里查是否有换行、空格、注释干扰 - 运行
SELECT CONSTRAINT_NAME, COLUMN_NAME FROM information_schema.KEY_COLUMN_USAGE WHERE TABLE_NAME = 'table_name' AND CONSTRAINT_NAME = 'PRIMARY' ORDER BY ORDINAL_POSITION，确认返回多行且ORDINAL_POSITION递增 - 检查 Navicat 连接源库时用的 MySQL 用户是否拥有
SELECT权限——权限不足时information_schema查询可能返回空，Navicat 就只能靠不完整的SHOW CREATE TABLE猜
Navicat 同步配置里哪些选项会加剧主键识别错误
不是所有“高级选项”都中立。以下几项在复合主键场景下实际起反作用：
-
Compare auto-increment value：勾选后 Navicat 会尝试提取AUTO_INCREMENT值，但它只认第一个主键字段上的自增属性，若复合主键中第二个字段才是自增列（极少见但合法），它会忽略并可能误删整个主键定义 -
Compare foreign keys：若外键引用的是复合主键中的非首字段，而 Navicat 没识别全主键列，就会报ERROR 1005 (HY000): Can't create table，错误指向外键而非主键本身 -
Compare comments和Compare collation同时开启时，若建表语句中注释跨行写在主键定义附近，Navicat 解析器可能把注释内容误吞进主键字段名里，导致字段名比对失败，进而放弃主键同步
绕过解析缺陷的实操底线
当确认是 Navicat 解析器局限（而非源库结构异常）导致复合主键丢失，不要反复调选项重试。最稳路径是人工干预生成脚本：
- 同步前务必勾选
Generate synchronization SQL script并保存文件 - 打开生成的 SQL，搜索
PRIMARY KEY，核对是否只有一列；若缺失，直接在CREATE TABLE语句末尾手动补全，例如加, PRIMARY KEY (id, tenant_id) - 禁用 Navicat 自动执行，改用命令行执行修正后的脚本：
mysql -h target_host -u user -p database_name
真正危险的不是 Navicat 没识别出复合主键，而是你没打开生成的 SQL 文件看一眼——它从不提示“我可能读错了”，只会安静地按错误理解去执行。
