Navicat中Ctrl多选设复合主键常只生效一个，因“主键”操作是逐行切换而非批量勾选；必须整行高亮后右键设主键，且所有字段须为NOT NULL、支持索引的类型，并确保无重复联合值。
Navicat 里 Ctrl 多选字段设主键，为什么有时只生效一个？
因为 navicat 的「主键」操作不是“批量勾选复选框”，而是“对当前选中行执行设为主键动作”。如果你用鼠标逐个点击字段左侧的钥匙图标（或直接点 pk 列），它会逐个切换状态——前一个会被取消，最后一个才保留。真正有效的多选方式是：按住 ctrl 键（macos 用 command），然后用鼠标左键依次点击多个字段所在行（整行高亮），再右键 → “主键”。
常见错误现象：PRIMARY KEY (col_a) 被意外生成，而不是预期的 PRIMARY KEY (col_a, col_b)；表结构里只看到一把锁带数字 1，另一列没锁标；查询 SHOW CREATE TABLE 发现只有一个字段在主键定义里。
- 必须确保所有目标字段已设置为
NOT NULL（Navicat 不会自动加，缺这个会报错） - 字段顺序会影响索引效率：把区分度高、常用于 WHERE 条件的字段放前面，比如
(tenant_id, order_no)比反过来更利于查询 - 如果表已有数据，Navicat 在保存时会检查联合值是否重复，遇到重复会中断并提示错误，不能跳过
设计表界面中“主键”图标显示为 1、2、3 是什么意思？
那是 Navicat 对复合主键字段的序号标记，主键1 表示该字段在 PRIMARY KEY 定义里的第一个位置，主键2 是第二个……不是优先级或权重，纯粹反映 ALTER TABLE ... PRIMARY KEY (a,b,c) 中的书写顺序。
这个序号直接影响 B+ 树索引的排序逻辑和范围查询能力。例如查询 WHERE a = ? AND b > ? 可走全索引，但 WHERE b = ? 就无法利用该联合主键做高效查找。
- 修改顺序只能删掉主键重设，不能拖拽调整
- 如果误点了非目标字段导致出现
主键3，得先取消它（右键 → “取消主键”），再重新 Ctrl 多选设定 - 导出 SQL 时，Navicat 生成的语句会严格按这些序号排列字段
为什么有时候右键“主键”菜单是灰色不可点？
通常有三个硬性前置条件未满足：字段非空、字段类型允许建索引、当前处于设计表编辑模式。Navicat 不会在界面上明确提示缺哪个，容易卡住。
典型场景包括：某字段类型是 TEXT 或 JSON（MySQL 不支持这类类型直接参与主键）；字段属性里勾了 NULL；或者你其实点的是“表数据”标签页，而非“设计表”标签页。
- 检查方式：回到“设计表”页 → 看每列的
Null列是否全为NO→ 看Type是否为VARCHAR/INT/CHAR等基础类型 -
TINYTEXT、MEDIUMTEXT同样不支持，必须改用VARCHAR(255)这类限定长度的类型 - 如果字段已存在数据且含 NULL 值，Navicat 会静默失败，需先用 SQL 清洗：
UPDATE tbl SET col = 'default' WHERE col IS NULL;
比起图形界面，手写 ALTER TABLE 更可靠吗？
是的，尤其对生产环境。Navicat 的可视化操作本质是拼装并执行一条 ALTER TABLE，但它隐藏了两个关键细节：索引名默认为 PRIMARY（不可改）、执行前不校验数据唯一性（直到最后一步才报错）。
手动执行可以控制节奏、提前验证、避免误操作扩散。比如先跑一遍去重检查：SELECT col_a, col_b, COUNT(*) FROM tbl GROUP BY col_a, col_b HAVING COUNT(*) > 1;，再执行：ALTER TABLE tbl DROP PRIMARY KEY, ADD PRIMARY KEY (col_a, col_b);
- 注意：MySQL 8.0+ 要求 DROP 和 ADD 必须在同一语句中完成，否则会报错“Multiple primary key defined”
- 如果原表已有自增 ID 主键，必须先
DROP PRIMARY KEY，否则ADD PRIMARY KEY (a,b)会失败 - Navicat 保存时若中途崩溃，可能留下半截无效结构，而 SQL 脚本可版本化、可回滚
复合主键的字段顺序、NOT NULL 约束、数据洁度，这三个点只要漏查一个，图形界面就会静默失败或生成错误结构，比写错一行 SQL 更难定位。
