REPLACE INTO 实际执行 DELETE + INSERT，非原地更新：会导致自增ID跳变、外键失败、触发器触发四次、binlog延迟风险高、并发下竞态丢失数据，应优先使用 ON DUPLICATE KEY UPDATE。
REPLACE INTO 不是主键冲突的“替代方案”，而是有明确副作用的操作，高并发下直接用它容易引发数据丢失和自增 ID 跳变。
REPLACE INTO 实际执行的是 DELETE + INSERT
MySQL 没有原地替换语义，REPLACE INTO 会先根据主键或唯一索引定位已有行，然后执行 DELETE，再执行 INSERT。这意味着：
- 如果表有外键约束（且未设
ON DELETE CASCADE），操作会失败并报错 - 自增 ID 一定会变化：即使只改一个字段，新记录也会获得新的
AUTO_INCREMENT值，旧 ID 永久丢失 - 触发器会触发两次（
BEFORE DELETE、AFTER DELETE、BEFORE INSERT、AFTER INSERT） - 在复制环境（如主从）中，
REPLACE产生的 binlog 是DELETE+INSERT两条事件，延迟和回放风险更高
并发下 REPLACE INTO 可能覆盖非预期数据
当多个线程同时对同一主键执行 REPLACE INTO，它们都成功完成 DELETE 后，最后的 INSERT 会覆盖中间所有变更——这不是“最终一致”，而是**竞态丢失**。
- 例如：A 线程想把
status = 'pending'改为'processing'；B 线程想把retry_count = 1加 1；两者都用REPLACE INTO，B 的INSERT可能覆盖 A 的status字段（如果 B 的 VALUES 没显式带 status） - 没有原子性保障：无法保证“读取当前值 → 计算新值 → 写入”这一完整流程不被中断
- 比
INSERT ... ON DUPLICATE KEY UPDATE更难审计，因为 DELETE 动作不可逆
为什么 ON DUPLICATE KEY UPDATE 更适合并发场景
INSERT ... ON DUPLICATE KEY UPDATE 是真正的“存在则更新”，不删除原行，也不重分配主键：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 所有字段更新都在单行原地完成，避免 ID 变化和外键断裂
- 支持表达式计算，比如
counter = counter + 1或updated_at = NOW()，且能正确处理NULL（需配合IFNULL()） - 影响行数可区分行为：
1表示插入，2表示更新，0表示被IGNORE（若用了INSERT IGNORE） - 在事务中更可控，尤其搭配
SELECT ... FOR UPDATE可实现强一致性逻辑（虽然通常没必要）
示例：INSERT INTO user_stats (user_id, login_count, last_login) VALUES (123, 1, NOW()) ON DUPLICATE KEY UPDATE login_count = IFNULL(login_count, 0) + 1, last_login = NOW();
真正要警惕的不是语法选型，而是唯一约束设计本身
很多主键冲突问题根源不在 INSERT 语句，而在表结构：
- 如果业务上本应靠自然键（如
order_no、email）去重，却只用id当主键，那REPLACE INTO或ON DUPLICATE KEY UPDATE都救不了——必须加UNIQUE KEY (order_no)或UNIQUE KEY (email) - 批量导入时出现冲突，优先检查源数据是否含重复值，而不是依赖 SQL 层“兜底”
- 分库分表场景下，全局 ID 生成器重复或时钟回拨，会导致跨分片主键冲突，这时换任何 MySQL 语法都没用
真正难处理的，永远是那些没被索引捕获的业务唯一性要求——语法只是最后一道防线，不是设计缺陷的创可贴。
