REPLACE INTO 本质是“删+插”，不是 UPDATE
REPLACE INTO看起来像插入，实际执行逻辑是：先按主键或唯一索引尝试查找记录；如果存在，就 先 DELETE 原行，再 INSERT 新行；如果不存在，直接 INSERT。这意味着自增 ID 可能变化、触发器会触发两次（DELETE + INSERT）、外键级联行为也会被触发——和
INSERT ... ON DUPLICATE KEY UPDATE完全不同。
常见错误现象：
REPLACE INTO users (id, name) VALUES (1, 'Alice')执行后发现
id没变，但
created_at时间重置了，或者关联的统计表数据异常——大概率是因为原记录被删掉了。 必须有主键或唯一索引才能触发“替换”逻辑，否则等同于普通
INSERT被删除的行仍计入
Affected rows，返回值可能是 2（删 1 行 + 插 1 行），别误判为失败 不适用于想保留原记录时间戳、版本号等字段的场景
什么时候该用 REPLACE 而不是 INSERT … ON DUPLICATE KEY UPDATE
真正适合
REPLACE INTO的场景其实很窄：你明确需要清空旧状态、重置所有字段（包括默认值、自动更新字段），且不介意自增 ID 变动或触发器重复执行。
典型例子：缓存表、临时聚合表、配置快照表——这些表本身就不依赖历史 ID 或严格顺序。
✅ 适合：REPLACE INTO config_cache (key, value) VALUES ('site_title', 'New Site')（无自增，纯 KV 替换）
❌ 不适合：REPLACE INTO orders (id, user_id, amount) VALUES (1001, 123, 99.9)（订单 ID 重用会导致关联流水丢失） ⚠️ 注意：
REPLACE不支持指定只更新部分列，整行都会被覆盖
REPLACE 的权限和性能影响
执行
REPLACE INTO需要同时具备
INSERT和
DELETE权限——很多人只授了 INSERT，结果报错
ERROR 1142 (42000): DELETE command denied。
性能上，它比
INSERT ... ON DUPLICATE KEY UPDATE多一次索引查找（先查再删）、一次磁盘写（DELETE 的 undo log + INSERT 的 redo log），高并发下锁粒度也更重（可能锁住整个唯一索引范围）。 检查权限命令：
SHOW GRANTS FOR CURRENT_USER，确认含
DELETE慢日志里看到大量
REPLACE且
Rows_examined较高，说明唯一键冲突频繁，应考虑改用
ON DUPLICATE KEY UPDATE在大表上慎用，尤其当唯一索引是非主键时，DELETE 可能引发二级索引回表开销
替代方案：INSERT … ON DUPLICATE KEY UPDATE 更可控
绝大多数“想替换”的需求，其实真正要的是“存在则更新部分字段”，这时
INSERT ... ON DUPLICATE KEY UPDATE是更安全、高效的选择。
例如：
INSERT INTO users (id, name, email) VALUES (1, 'Bob', 'bob@example.com') ON DUPLICATE KEY UPDATE name=VALUES(name), email=VALUES(email)—— ID 不变、时间戳不重置、触发器只触发一次。
VALUES(col)引用的是 INSERT 子句中对应列的值，不是当前行值 支持条件更新：
ON DUPLICATE KEY UPDATE updated_at = IF(VALUES(updated_at) > updated_at, VALUES(updated_at), updated_at)如果表没有主键/唯一索引，语句会退化为普通 INSERT，不会报错 REPLACE 的“替换”二字容易误导人以为它是轻量更新，实际它是一次破坏性操作。用之前，先确认你真的需要删掉旧记录，而不是修修补补。
