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 行影响。整个过程不省资源，只省报错。
- 并发越高，多个线程在同一个唯一索引上反复做“查找 + 锁等待”，容易形成锁队列，表现为写入延迟陡增
- 如果表有多个唯一索引（比如
uk_email和uk_phone），只要任一命中就跳过，但查找开销不减，白花 CPU -
mysql_affected_rows()返回 0 时，你无法区分是真重复，还是字段超长被截断、外键缺失等其他约束失败——结果只能重试或打日志，进一步拖慢链路
REPLACE INTO 的隐性成本远超预期
它根本不是“更新”，是 DELETE + INSERT 两步原子操作，每冲突一次，就多一次磁盘 I/O、一次 binlog 写入、两次触发器执行、一次自增 ID 消耗。
- 自增主键表中，
REPLACE INTO即使指定id，也会让AUTO_INCREMENT值跳变，后续插入可能跨页，影响 B+ 树局部性 - 若关联表设了
ON DELETE CASCADE，一次冲突会意外级联删子记录，再重建——业务逻辑完全失控 - 时间戳字段（如
created_at DEFAULT CURRENT_TIMESTAMP）必然重置，丢失原始创建时间，且无法通过 SQL 层面规避
ON DUPLICATE KEY UPDATE 怎么用才不卡？
它才是真正语义清晰、开销可控的 upsert，但生效前提是：表必须有明确的 PRIMARY KEY 或 UNIQUE KEY，且冲突必须由这些索引触发。
- 确保只对业务真正需要去重的字段建唯一索引，避免冗余索引增加写入负担；例如用户表用
uk_openid而非uk_email, uk_phone, uk_unionid全堆 - 批量插入时，
VALUES(col)引用当前行值最安全，但 MySQL 8.0.20+ 已标记为 deprecated，新项目建议改用预编译参数（score = ?）避免解析歧义 - 累加类更新（如
count = count + VALUES(count)）无锁，高并发下可能丢更新；若需强一致，得搭配SELECT ... FOR UPDATE或应用层幂等控制 - 多个唯一索引共存时，MySQL 只按索引定义顺序匹配第一个冲突项，UPDATE 不会跨索引生效——别指望靠
uk_email冲突去更新uk_phone对应的行
真正容易被忽略的点是：唯一索引本身是双刃剑。它加速冲突检测，但也让每次插入都多一次索引维护开销。如果你的“去重”只是临时业务逻辑（比如防消息重复消费），不如在应用层用 Redis 做短时效去重，把数据库压力卸下来。数据库层的唯一索引，该用在数据模型强约束的地方，而不是补救设计缺陷的创可贴。
