怎样在MySQL中处理由于唯一索引重复冲突导致的插入性能毛刺？

ON DUPLICATE KEY UPDATE才是安全可控的“存在则更新”方案，它仅在主键或唯一索引冲突时原子化更新指定字段，不重置ID、不触发级联删除、不增加额外I/O；而INSERT IGNORE仍执行完整插入流程并加锁，REPLACE INTO实为DELETE+INSERT，开销翻倍。

直接说结论：唯一索引冲突本身不会导致“性能毛刺”，真正拖慢的是你选错处理方式后引发的额外 I/O、锁等待或事务重试——INSERT IGNORE 和 REPLACE INTO 在高并发下最容易放大这个问题，而 ON DUPLICATE KEY UPDATE 配合合理索引设计才是稳态写入的解法。

为什么 INSERT IGNORE 在高并发下反而更慢？

它不是“跳过就完事”，而是完整走一遍插入流程：解析 SQL → 检查所有唯一索引 → 定位冲突行 → 加锁（即使是共享锁）→ 判定冲突 → 返回 0 行影响。整个过程不省资源，只省报错。

1. 并发越高，多个线程在同一个唯一索引上反复做“查找 + 锁等待”，容易形成锁队列，表现为写入延迟陡增
2. 如果表有多个唯一索引（比如 uk_email 和 uk_phone），只要任一命中就跳过，但查找开销不减，白花 CPU
3. mysql_affected_rows() 返回 0 时，你无法区分是真重复，还是字段超长被截断、外键缺失等其他约束失败——结果只能重试或打日志，进一步拖慢链路

REPLACE INTO 的隐性成本远超预期

它根本不是“更新”，是 DELETE + INSERT 两步原子操作，每冲突一次，就多一次磁盘 I/O、一次 binlog 写入、两次触发器执行、一次自增 ID 消耗。

1. 自增主键表中，REPLACE INTO 即使指定 id，也会让 AUTO_INCREMENT 值跳变，后续插入可能跨页，影响 B+ 树局部性
2. 若关联表设了 ON DELETE CASCADE，一次冲突会意外级联删子记录，再重建——业务逻辑完全失控
3. 时间戳字段（如 created_at DEFAULT CURRENT_TIMESTAMP）必然重置，丢失原始创建时间，且无法通过 SQL 层面规避

ON DUPLICATE KEY UPDATE 怎么用才不卡？

它才是真正语义清晰、开销可控的 upsert，但生效前提是：表必须有明确的 PRIMARY KEY 或 UNIQUE KEY，且冲突必须由这些索引触发。

1. 确保只对业务真正需要去重的字段建唯一索引，避免冗余索引增加写入负担；例如用户表用 uk_openid 而非 uk_email, uk_phone, uk_unionid 全堆
2. 批量插入时，VALUES(col) 引用当前行值最安全，但 MySQL 8.0.20+ 已标记为 deprecated，新项目建议改用预编译参数（score = ?）避免解析歧义
3. 累加类更新（如 count = count + VALUES(count)）无锁，高并发下可能丢更新；若需强一致，得搭配 SELECT ... FOR UPDATE 或应用层幂等控制
4. 多个唯一索引共存时，MySQL 只按索引定义顺序匹配第一个冲突项，UPDATE 不会跨索引生效——别指望靠 uk_email 冲突去更新 uk_phone 对应的行

真正容易被忽略的点是：唯一索引本身是双刃剑。它加速冲突检测，但也让每次插入都多一次索引维护开销。如果你的“去重”只是临时业务逻辑（比如防消息重复消费），不如在应用层用 Redis 做短时效去重，把数据库压力卸下来。数据库层的唯一索引，该用在数据模型强约束的地方，而不是补救设计缺陷的创可贴。