REPLACE INTO本质是“删+插”，非更新：先按主键或唯一索引查找，存在则DELETE原行再INSERT新行，否则直接INSERT；导致自增ID可能变化、触发器执行两次、外键级联触发。
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 或严格顺序。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- ✅ 适合：
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，不会报错
