Navicat设联合主键必须按Ctrl（Windows）或Command（macOS）多选字段后统一设主键，否则单次操作会覆盖之前主键；所有字段须已保存、非空且非TEXT/BLOB类型，顺序影响索引匹配与存储效率，外键依赖需手动处理。
Navicat 多选字段设联合主键必须按 Ctrl+单击，不能逐个右键
navicat 的“设为主键”是覆盖式操作：每次单击某一行再右键 → “设为主键”，都会清掉之前所有主键定义，只保留当前这一列。这不是 bug，是设计逻辑。想设联合主键，必须先用 ctrl（windows）或 command（macos）多选多个字段行，再统一右键 → “设为主键”。ui 上会显示 pk 1、pk 2 等编号，表示它们共同构成一个主键。
常见错误现象：点了两列，但保存后只有最后一列带钥匙图标——说明你没多选，而是分两次点的。
- 字段必须全部已存在且已保存进表结构（未保存的新增字段无法参与主键）
- 所有参与列都必须勾选
NOT NULL，否则保存失败且无明确提示 - 如果某列类型是
TEXT或BLOB，Navicat 会拒绝设主键，需先改类型为VARCHAR并指定长度
保存前务必看预览 SQL，警惕隐式 NOT NULL 变更
Navicat 执行联合主键时，底层实际运行的是 ALTER TABLE `table_name` ADD PRIMARY KEY (`col1`, `col2`)。但如果其中任一列原来允许 NULL，这条语句会隐式加上 NOT NULL 约束——而 MySQL 要求主键列非空，所以它不得不这么做。问题在于：如果该列已有 NULL 值，执行会直接报错 ERROR 1171 (HY000): All parts of a PRIMARY KEY must be NOT NULL。
解决办法只有两个：
- 提前清理数据：
UPDATE table_name SET col1 = 'default' WHERE col1 IS NULL; - 或先手动加
NOT NULL：ALTER TABLE table_name MODIFY col1 VARCHAR(50) NOT NULL;，再设主键
别跳过“预览 SQL”步骤——点击 Apply 后弹出的窗口里，一定要确认生成的语句是否含 MODIFY 或 CHANGE，那意味着结构变更已发生。
联合主键字段顺序决定索引最左前缀匹配能力
Navicat 按你在设计表中从上到下的顺序排列联合主键字段。比如你先选 order_date 再选 user_id，生成的就是 PRIMARY KEY (`order_date`, `user_id`)。这个顺序直接影响查询能否命中主键索引。
例如，以下查询能走主键索引：
SELECT * FROM orders WHERE order_date = '2026-07-01' AND user_id = 123;
但这个不行：
SELECT * FROM orders WHERE user_id = 123;
因为缺少最左列 order_date，MySQL 无法使用该复合索引。如果你高频查 user_id，就把 user_id 放主键第一位。
- 顺序不能靠拖拽调整，只能删掉重设或手写
ALTER TABLE - 主键即聚簇索引，顺序也影响磁盘存储和范围扫描效率
外键依赖存在时，Navicat 不会自动处理，得手动破除
如果另一张表用 FOREIGN KEY 引用了当前表，Navicat 点 Apply 会报错：Cannot add or update a child row: a foreign key constraint fails。它不会提示你哪张表在依赖，也不会帮你删外键。
先查依赖关系：
SELECT CONSTRAINT_NAME, TABLE_NAME FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE REFERENCED_TABLE_NAME = 'your_table';
然后要么：
- 去依赖表里删外键：
ALTER TABLE other_table DROP FOREIGN KEY fk_name; - 或在 Navicat 的“Foreign Keys”标签页里手动编辑/删除对应外键
- 或者改用级联：在依赖表外键定义里加
ON DELETE CASCADE，但要评估业务影响
联合主键不是“多点几下就能好”的操作，字段顺序、NULL 状态、外键链路、已有重复数据——四个点里漏一个，保存就卡住。别信 UI 上那把小钥匙图标，最终以 SHOW CREATE TABLE 输出为准。
