“yyy”是触发冲突的索引名，对应表中主键、UNIQUE约束或唯一索引；执行SHOW CREATE TABLE可定位其所属表与字段，若为PRIMARY或自定义名（如uk_email）则分别对应主键或显式唯一索引，外键列也可能被自动加唯一索引。
查清是哪个唯一约束在报错
MySQL 的 Duplicate entry 'xxx' for key 'yyy' 错误里，'yyy' 就是触发冲突的索引名，它可能是主键、UNIQUE 约束，也可能是唯一索引。别急着改代码，先确认这个 yyy 对应哪张表、哪个字段：
- 执行
SHOW CREATE TABLE `table_name`;，搜索UNIQUE KEY或PRIMARY KEY，看yyy是否在里面 - 如果
yyy是形如uk_user_email这种自定义名，基本可确定是显式创建的唯一索引；如果是PRIMARY或email（字段名），说明冲突发生在主键或该字段的唯一约束上 - 注意：InnoDB 中，即使没显式加
UNIQUE，但某列被用作外键参照目标时，MySQL 会自动为其加唯一索引（仅限单列外键），这也可能成为报错源头
确认重复值是否真由业务逻辑导致
不是所有重复都来自并发——有些是代码漏校验、缓存未失效、或上游重复推送。用 SELECT 直接验证最可靠：
- 假设报错是
Duplicate entry 'alice@example.com' for key 'uk_email'，立刻执行：SELECT id, email, created_at FROM users WHERE email = 'alice@example.com';
- 如果返回多行 → 真实数据已脏，检查插入前是否做了
SELECT ... FOR UPDATE或应用层幂等控制 - 如果只返回一行，但插入仍报错 → 很可能是事务隔离级别 + 并发写入导致（比如两个事务同时读到“不存在”，然后都尝试插入）
- 特别注意：如果字段含前导/尾随空格或大小写（如
utf8mb4_0900_as_cs排序规则下'A'≠'a'），而应用层未统一 trim / normalize，也会看似“不重复”实则数据库判定重复
并发插入场景下避免 Duplicate entry 的常用手段
单纯靠 INSERT IGNORE 或 ON DUPLICATE KEY UPDATE 能压住错误，但掩盖了问题本质。真正健壮的做法需分层应对：
- 应用层加分布式锁（如 Redis SETNX）控制关键路径，粒度尽量小，比如锁
email:alice@example.com而非整个用户表 - 数据库层用
INSERT ... SELECT ... WHERE NOT EXISTS替代简单 INSERT，例如：INSERT INTO users (email, name) SELECT 'alice@example.com', 'Alice' FROM DUAL WHERE NOT EXISTS (SELECT 1 FROM users WHERE email = 'alice@example.com');
—— 这条语句在可重复读（RR）隔离级别下能避免幻读干扰 - 若必须用
ON DUPLICATE KEY UPDATE，确保更新字段是幂等的（如updated_at = NOW()），而非counter = counter + 1这类非幂等操作，否则并发下结果不可预期 - 避免在高并发写入场景中依赖应用层“先查后插”（check-then-act），因为查和插之间存在时间窗口，且 MySQL 默认 RR 隔离级别下
SELECT不加锁
为什么 SHOW ENGINE INNODB STATUS 看不到死锁却仍有 Duplicate entry
这是常见误解：Duplicate entry 和死锁无关，它发生在插入阶段的唯一性检查环节，属于约束校验失败，不是锁等待超时。所以即使 SHOW ENGINE INNODB STATUS 没有死锁记录，也不能排除并发问题。
- InnoDB 在插入前会为待插入记录的唯一键值加“插入意向锁”（Insert Intention Lock），再检查唯一索引；若发现已有相同键值的记录（无论是否已提交），就直接报错，不进入锁等待队列
- 这意味着：两个事务几乎同时插入同一唯一值，大概率都收到
Duplicate entry，而不是一个成功一个阻塞——这正是并发判断缺失的典型信号 - 真正要排查并发压力，得结合慢日志里的
Rows_examined、应用层重试次数、以及监控中Com_insert与Handler_write的比率突增
唯一索引冲突表面是数据问题，根子常在并发控制缺位或校验逻辑断层。最危险的是用 INSERT IGNORE 当兜底还沾沾自喜——它不报错，但可能让本该拒绝的非法状态悄然入库。
