应优先用 INSERT ... ON DUPLICATE KEY UPDATE 替代 DELETE + INSERT，因其为原子操作、仅一次索引查找、避免锁竞争和数据真空；REPLACE INTO 本质仍是删再插，有自增ID跳变等风险；批量操作需分批控制事务粒度。
频繁 DELETE + INSERT 组合，本质上是“先删后插”，但直接这么干极易锁表、拖慢事务、触发大量索引重建——应优先用 REPLACE INTO 或 INSERT ... ON DUPLICATE KEY UPDATE 替代。
为什么不能直接交替执行 DELETE 和 INSERT？
MySQL 中连续执行 DELETE 再 INSERT，哪怕主键相同，也会触发两轮索引操作（删索引 + 插索引），且中间存在短暂的“数据真空期”，若并发读取可能看到空结果；更关键的是，InnoDB 会为这两条语句分别加行锁或间隙锁，锁持有时间翻倍，极易引发锁等待甚至死锁。
- DELETE 操作需遍历索引定位并标记删除，再清理 undo log
- INSERT 操作需重新分配页、写 redo、更新所有相关索引
- 两者之间若无显式事务包裹，还可能出现部分成功、部分失败的不一致状态
用 INSERT ... ON DUPLICATE KEY UPDATE 替代 DELETE+INSERT
当目标表有唯一键（如 UNIQUE 约束或主键）时，INSERT ... ON DUPLICATE KEY UPDATE 是原子操作：命中冲突则更新，否则插入。它只走一次索引查找，避免二次定位和锁竞争。
- 必须确保冲突列上有唯一索引，否则语句不生效（也不会报错）
- 更新字段不能包含自增列本身，但可更新其他列，例如：
INSERT INTO user (id, name, status) VALUES (123, 'Alice', 'active') ON DUPLICATE KEY UPDATE name = VALUES(name), status = VALUES(status) - 注意
VALUES(col)是语法糖，表示本次 INSERT 中该列的值，不是函数调用 - 如果业务逻辑需要“覆盖全部字段”，就老老实实列出所有非主键字段；若只需更新部分字段，只写对应字段即可
REPLACE INTO 的代价与适用边界
REPLACE INTO 看似简洁，但它底层是“DELETE + INSERT”两步，只是封装成一条语句。它会先按唯一键查出旧行并删除（触发 DELETE 触发器、生成 undo 日志），再插入新行。因此它仍会引发双倍索引维护开销，并可能让自增 ID 跳变。
- 仅在明确接受自增 ID 不连续、且表上无复杂触发器/外键级联时才考虑使用
- 对高并发写入场景尤其危险：两个
REPLACE同时命中同一行，可能产生幻读或主键冲突重试 - 比
ON DUPLICATE KEY UPDATE多一次磁盘写入（delete 阶段的 page split / merge 可能更剧烈）
批量场景下必须控制单次语句长度和事务粒度
即使改用 ON DUPLICATE KEY UPDATE，一次性提交几万行仍会导致长事务、大日志、锁范围扩大。实际部署中要拆分批次，并手动管理事务。
- 单条
INSERT ... ON DUPLICATE KEY UPDATE建议不超过 1000 行，避免超过max_allowed_packet限制 - 每批执行后显式
COMMIT，不要依赖自动提交；必要时用START TRANSACTION包裹整批 - 避免在事务中混入 SELECT 或其他 DML，防止锁范围意外扩大
- 如果目标表有大量二级索引，考虑临时
DROP INDEX再重建（仅限离线维护窗口）
真正难的不是写出替代语句，而是判断“哪些字段必须更新”“哪些冲突才算有效”“是否允许短暂不一致”。这些逻辑一旦嵌入 SQL，就很难动态调整——所以最终落地时，往往得把冲突判定逻辑收回到应用层做兜底校验。
