主键冲突本身不直接引发关联异常，但常是外键失效或级联崩坏的前置原因；外键必须引用唯一且非空的列（主键或带UNIQUE约束的字段），否则会导致JOIN错乱、CASCADE误删、缓存冲突等问题。
主键冲突本身不会直接导致“关联异常”，但它是外键约束失效或级联操作崩坏的常见前置原因。必须先确认：你遇到的是 INSERT 报错，还是 JOIN 结果错乱、UPDATE 失效、DELETE 连带删错数据？前者是主键问题，后者大概率是外键没建、ON DELETE 行为不匹配，或唯一约束缺失。
为什么外键依赖唯一约束，而不是主键本身
外键（FOREIGN KEY）必须引用一个 唯一且非空 的列组合——它可以是主键，也可以是带 UNIQUE 约束的普通字段（比如 email 或 tenant_id + external_id）。如果只在被引用表上建了主键，但关联字段是另一个非主键列（例如用 user_code 关联），而该列没加 UNIQUE，那么：
- 插入重复
user_code不会报主键冲突，但会导致外键引用歧义 -
JOIN可能返回多行，业务逻辑误判“一对一”关系 -
ON DELETE CASCADE可能误删多条记录 - 应用层缓存 key 冲突（比如用
user_code当 Redis key）
所以，“建立唯一约束”不是补救措施，而是定义关联语义的强制前提。
如何验证并补全缺失的唯一约束
别猜。用数据库原生命令确认当前约束状态：
- MySQL：
SHOW CREATE TABLE orders;—— 检查输出里是否有UNIQUE KEY `uk_user_code` (`user_code`)，而不仅是PRIMARY KEY (`id`) - PostgreSQL：
\d orders—— 查看Indexes:区域，确认目标字段是否出现在UNIQUE索引行中 - 如果缺失，立刻加：
ALTER TABLE orders ADD UNIQUE (user_code); - 加之前先清理重复：
DELETE o1 FROM orders o1 INNER JOIN orders o2 WHERE o1.user_code = o2.user_code AND o1.id > o2.id;
注意：加 UNIQUE 会锁表（尤其大表），生产环境建议在低峰期执行，并提前评估索引大小对写性能的影响。
INSERT 时主键冲突 + 外键引用失败的典型链式错误
常见于同步脚本或 ETL 场景：源表有 user_id，目标表用它作外键，但目标表的 users 主表没同步成功，导致 user_id 在 users 中不存在 → 插入 orders 时触发 ERROR 1452 (23000): Cannot add or update a child row。这不是主键冲突，但常被误认为是。
- 根本原因：主表缺失数据，而非子表主键重复
- 检查顺序必须是：
SELECT id FROM users WHERE id = ?→ 若无结果，说明主表没写入，或写入时自己就因主键冲突失败了 - 修复路径：先 fix
users表的插入逻辑（用INSERT ... ON DUPLICATE KEY UPDATE或UPSERT），再重试orders - 预防：在同步任务中，把主表写入和子表写入放在同一事务中，或用
INSERT IGNORE+ 后置校验
复合外键场景下唯一约束容易漏写的点
当外键引用多个字段（如 (tenant_id, user_id)）时，唯一约束必须覆盖整个组合，不能只给单个字段加 UNIQUE：
- 错误写法：
ALTER TABLE users ADD UNIQUE (tenant_id); ALTER TABLE users ADD UNIQUE (user_id);—— 这允许(1001, 1)和(1001, 1)同时存在（因为tenant_id和user_id单独都不重复） - 正确写法：
ALTER TABLE users ADD UNIQUE (tenant_id, user_id); - PostgreSQL 中，
ON CONFLICT必须显式写成ON CONFLICT (tenant_id, user_id)，否则报错there is no unique or exclusion constraint matching... - MySQL 的
ON DUPLICATE KEY UPDATE会响应任意命中该复合唯一索引的冲突，但更新逻辑仍只作用于SET列表中的字段
真正难排查的是：约束名没起好，或者开发时用 ORM 自动生成表结构却忘了配 unique=True，上线后靠报错才暴露——这种问题往往在灰度发布阶段突然爆发，且只影响特定租户或数据分区。
