MySQL和PostgreSQL均不支持直接修改复合主键，必须先删除再重建；操作时需注意外键依赖、AUTO_INCREMENT属性、NULL值约束及索引排序对查询性能的影响。
MySQL Workbench 里改复合主键，点几下就完事？
不能直接“调整”现有主键包含的列——mysql 不支持 alter table ... modify primary key 这种语法。必须先删掉旧主键，再建新主键。workbench 界面看似能拖拽编辑，其实只是在生成 drop + add 语句，背后仍是重建。
- 右键表 → Edit Table → 切到
Indexes标签页，找到PRIMARY索引 - 删掉它：选中
PRIMARY行，点上方-按钮（不是右键菜单里的“Remove”，那个只删索引定义不删约束） - 新建主键：点
+，类型选PRIMARY，然后在下方Columns区域勾选你要包含的列（顺序很重要！） - 保存时 Workbench 会弹出 SQL 预览，务必确认它生成的是
DROP PRIMARY KEY和ADD PRIMARY KEY (...)，而不是MODIFY或CHANGE
ALTER TABLE 手动写 SQL 重建复合主键更稳
界面操作容易漏掉隐式依赖：比如有外键引用该主键、或列上有 AUTO_INCREMENT、或字段类型不兼容（如 TEXT 不能做主键）。手动写 SQL 能提前看清约束和报错。
- 先查当前主键结构：
SHOW CREATE TABLE `your_table`;，看PRIMARY KEY后面括号里的列名和顺序 - 删主键：
ALTER TABLE `your_table` DROP PRIMARY KEY;（注意：如果主键含 AUTO_INCREMENT 列，这一步会同时去掉该属性，得后续补回） - 加新主键：
ALTER TABLE `your_table` ADD PRIMARY KEY (col_a, col_b, col_c);（列顺序决定索引排序逻辑，影响范围查询性能） - 如果原主键有 AUTO_INCREMENT，且你仍想保留在第一列，得在 ADD 语句后单独执行：
ALTER TABLE `your_table` MODIFY col_a BIGINT UNSIGNED AUTO_INCREMENT;
PostgreSQL 怎么办？它不叫“主键”，是“主键约束”
PostgreSQL 没有“修改主键”的概念，只有删除并重加约束。而且它的主键自动创建唯一 B-tree 索引，删约束 = 删索引，这点比 MySQL 更透明。
- 查当前主键约束名：
\d your_table或SELECT conname FROM pg_constraint WHERE conrelid = 'your_table'::regclass AND contype = 'p'; - 删约束：
ALTER TABLE your_table DROP CONSTRAINT your_pkey_name;（别硬写PRIMARY KEY，必须用真实约束名） - 加新约束：
ALTER TABLE your_table ADD PRIMARY KEY (col_x, col_y);（会自动建同名索引） - 注意：如果新主键列含 NULL 值，会直接报错
ERROR: column "col_x" contains null values，MySQL 允许主键列隐式 NOT NULL，但 PG 要求显式保证
改复合主键最容易被忽略的三个点
不是语法跑通就完事。真正出问题的，往往在边界场景。
- 外键阻塞：如果有其他表的外键指向这个主键，
DROP PRIMARY KEY会失败（MySQL 8.0+ 默认开启foreign_key_checks=ON），得先删外键或临时关检查（不推荐） - 索引重复：新加的主键列组合，如果已有唯一索引覆盖，MySQL 会复用它；但 PostgreSQL 不会，一定新建索引，磁盘空间和锁时间都多一倍
- 排序变更影响查询：比如原主键是
(tenant_id, created_at)，改成(created_at, tenant_id)，原来WHERE tenant_id = ? ORDER BY created_at的查询可能从索引扫描退化成文件排序
改之前导出当前主键定义和关键查询的 EXPLAIN 结果，改完立刻比对——这才是真正落地的验证方式。
