唯一键冲突检查发生在存储引擎层写入数据前，引擎对每个唯一索引执行b+树查找，任一命中即中止并报错1062；on duplicate key update则在查到冲突后不报错，直接定位原行执行更新，是引擎原生支持的原子操作。
唯一键冲突检查发生在INSERT执行的哪个阶段？
冲突检查不是在语法解析或预处理阶段发生的，而是在存储引擎层真正写入数据前的最后一道校验。MySQL Server层把 INSERT 请求下推给InnoDB（或其他引擎）后，引擎会先尝试定位目标行——对每个唯一索引（包括主键）执行一次B+树查找，确认是否已存在相同键值的记录。
这个过程是原子性的：只要任一唯一索引命中冲突，整个INSERT就会中止，并返回错误码 1062；不会等到所有索引都查完才判断，而是“第一个冲突即终止”。
- 如果表有多个唯一索引（比如
email和phone都设了UNIQUE），只要其中任意一个匹配上已有值，就触发冲突 - 冲突检查不区分“主键”和“唯一索引”，它们在引擎层地位一致，都是B+树索引查找
- 即使你只插入部分字段（比如没填
email），只要其他字段组合触发了某个唯一索引的重复，照样报错
为什么ON DUPLICATE KEY UPDATE能绕过“报错退出”流程？
它不是跳过冲突检查，而是让引擎在发现冲突后不返回错误，而是立刻转入“更新路径”。底层行为是：引擎查到重复键后，不抛 ER_DUP_ENTRY，而是直接定位到那条已有记录，复用其行锁，并执行UPDATE子句中指定的列赋值。
关键点在于：ON DUPLICATE KEY UPDATE 的语义被InnoDB原生支持，整个过程仍是一次性原子操作，不会出现“先报错再捕获再更新”的用户态重试逻辑。
-
VALUES(column_name)在UPDATE子句里不是函数调用，而是SQL层保留字，指向本次INSERT本该写入的值，由Server层在生成执行计划时就绑定好了 - 如果UPDATE子句里更新的是非唯一索引字段（如
status），不会再次触发唯一性检查——除非你恰好更新了另一个唯一键字段并造成新冲突 - 受影响行数为2，说明引擎确实走的是“查到→锁定→更新”路径，而非“插入失败→回退→再更新”
INSERT IGNORE和REPLACE INTO的冲突处理为什么不可控？
INSERT IGNORE 本质是把所有约束冲突（主键、唯一索引、外键、NOT NULL、CHECK）全部降级为警告，且不提供区分手段。你看到 mysql_affected_rows() 返回0，无法判断是重复、字段超长，还是外键不存在。
REPLACE INTO 则完全绕开冲突检测逻辑：它先按主键或唯一键做一次DELETE（触发 BEFORE DELETE），再执行INSERT（触发 BEFORE INSERT），中间可能释放行锁、重置自增ID、触发级联动作——这些都不是“UPSERT”本意。
- 并发场景下，
REPLACE INTO的DELETE+INSERT两步之间存在窗口期，其他事务可能插入同键值记录，导致最终数据不一致 -
INSERT IGNORE在批量插入时，某一行因唯一键冲突被忽略，但后续行仍继续执行，无法保证整体原子性 - 二者都不支持像
ON DUPLICATE KEY UPDATE那样对冲突行做条件更新（比如login_count = login_count + 1）
如何验证当前语句到底触发了哪个唯一索引的冲突？
错误信息里的 for key 'xxx' 是唯一线索，但生产环境常因动态建表或ORM生成字段名导致key名难读。更可靠的方式是查 INFORMATION_SCHEMA.STATISTICS：
SELECT INDEX_NAME, COLUMN_NAME FROM INFORMATION_SCHEMA.STATISTICS WHERE TABLE_SCHEMA = 'your_db' AND TABLE_NAME = 'your_table' AND NON_UNIQUE = 0;
结合报错中的键值（如 Duplicate entry 'alice@example.com' for key 'uk_email'），就能反推出是哪个唯一索引字段出了问题。
- 注意：MySQL 8.0+ 中，如果使用表达式索引或函数索引，错误信息里的键值可能是计算后的结果，不一定对应原始字段值
- 如果表没有显式命名唯一索引，MySQL会自动生成类似
uk_2这样的名字，需靠COLUMN_NAME辅助定位 - 不要依赖错误消息中的字段名拼写——有些版本会截断长名，或显示内部别名
UNIQUE(email, tenant_id)，但代码里只校验了 email 是否重复，漏掉租户维度，照样会撞上 1062。
