MySQL不支持双主键，只支持由多列组成的复合主键；它要求组合值唯一且非空，但单列可重复，顺序影响存储、查询性能及索引使用效果。
MySQL 不支持“双主键”，只支持复合主键
MySQL 里不存在两个独立主键的概念。所谓“双主键”，实际是一个由两列（或更多列）共同构成的复合主键，它仍是一个主键，只是值的唯一性依赖于字段组合。执行 ALTER TABLE t ADD PRIMARY KEY (a, b); 后，(a,b) 整体必须唯一且非空，但单看 a 或单看 b 都可以重复。
常见错误现象：
– 执行 ALTER TABLE t ADD PRIMARY KEY (a, b); 报错 ERROR 1048 (23000): Column 'a' cannot be null 或 ERROR 1062 (23000): Duplicate entry 'x-y' for key 'PRIMARY'；
– 误以为加了复合主键后还能再加另一个 PRIMARY KEY，结果触发语法错误 ERROR 1068 (42000): Multiple primary key defined。
实操前必须确认：
– SELECT COUNT(*) FROM t WHERE a IS NULL OR b IS NULL; 结果为 0
– SELECT a, b, COUNT(*) FROM t GROUP BY a, b HAVING COUNT(*) > 1; 无返回行
– 大表建议先在从库验证，避免 ALTER 锁表时间过长
复合主键顺序直接影响 INSERT/UPDATE 性能和 WHERE 查询行为
复合主键本质是 MySQL 的聚簇索引，数据物理存储顺序就按主键列顺序排列。这意味着：
– PRIMARY KEY (user_id, order_seq)：数据按 user_id 分组，组内再按 order_seq 排序；
– PRIMARY KEY (order_seq, user_id)：数据全局按 order_seq 排，user_id 只是次要排序因子。
使用场景决定顺序：
– 若常查 WHERE user_id = ? 或 WHERE user_id = ? AND order_seq BETWEEN ? AND ?，优先把 user_id 放左边；
– 若业务按时间范围批量归档（如 WHERE order_seq > 1000000），且 order_seq 是单调递增的，可考虑把它放最左——但要注意这会导致 user_id 值在磁盘上高度离散，点查性能下降；
– INSERT 时若主键顺序与写入顺序不一致（比如 PRIMARY KEY (status, id) 但 id 自增），会引发大量页分裂，写放大明显。
复合索引和复合主键对查询条件顺序的要求完全一致
无论是普通复合索引还是复合主键，都严格遵守最左前缀原则。例如主键为 (a, b, c)：
– WHERE a = 1 ✅ 走主键索引
– WHERE a = 1 AND b > 10 ✅ 走 a 和 b，c 不参与索引查找
– WHERE a = 1 AND c = 3 ❌ c 不走索引（跳过了 b）
– WHERE b = 2 ❌ 整个主键索引失效，只能全表扫描
容易被忽略的细节：
– ORDER BY 字段顺序必须与主键/索引顺序一致才免 filesort，比如 ORDER BY a, b 可用 (a,b,c) 主键，但 ORDER BY b, a 就不行；
– GROUP BY 同理，不匹配顺序就会触发临时表；
– 如果查询中只用到 SELECT a, b，而主键是 (a,b,c)，则属于索引覆盖，无需回表——但前提是 SELECT 列必须全部包含在主键定义中（不含额外字段）。
什么时候该用复合主键，而不是单主键 + 普通复合索引？
核心判断依据是：业务语义是否天然要求多列联合唯一。
适合用复合主键的典型场景：
– 订单明细表：PRIMARY KEY (order_id, product_id)，因为同一订单里不能重复添加同一商品；
– 多租户配置表：PRIMARY KEY (tenant_id, config_key)，每个租户的配置项 key 必须唯一；
– 关系表（如用户-角色关联）：PRIMARY KEY (user_id, role_id)，避免重复授权。
不适合强行用复合主键的情况：
– 表本身已有自增 id 主键，又额外加 PRIMARY KEY (a,b) → 直接报错，MySQL 不允许两个主键；
– 某列（如 status）选择性极低（只有 0/1），却硬塞进主键左边 → 导致大量数据挤在同一索引页，范围查询效率反而更差；
– 后续要频繁更新主键列（如 UPDATE t SET a = ? WHERE b = ?）→ 更新主键等于移动数据行位置，开销远高于更新普通字段。
真正难处理的不是语法怎么写，而是想清楚：这个“联合唯一”是数据本身的约束，还是仅仅为了加速某类查询？前者用复合主键，后者加普通复合索引就够了。很多人卡在这一步，一上来就堆字段，结果既没解决业务约束，又拖慢了写入。
