REPLACE INTO 本质是 DELETE + INSERT 而非 UPDATE，会先删除匹配主键或唯一索引的旧行再插入新行，导致自增 ID 变化、触发器执行两次、外键级联按删除逻辑触发，且未指定字段将设为默认值或 NULL。
REPLACE INTO 本质是 DELETE + INSERT，不是 UPDATE
很多人以为 REPLACE INTO 是 UPDATE 的快捷写法，实际它会先尝试根据主键或唯一索引匹配行，若存在则**先删除再插入**。这意味着自增 ID 会变化、触发器会执行两次（DELETE 和 INSERT 各一次）、外键级联行为也会按删除逻辑触发。
典型误用场景：想更新用户最后登录时间，但表里有 id 主键和 email 唯一索引，用 REPLACE INTO users (id, email, last_login) VALUES (1, 'a@b.com', NOW()) —— 如果只改了 last_login，但 email 不变，仍会删掉原记录再插一条，id 不变（因为显式指定了），但如果有其他字段没在 VALUES 中提供，就会变成默认值或 NULL。
- 必须确保表有主键或至少一个 UNIQUE 约束，否则
REPLACE INTO等同于普通INSERT - 被替换的行的 AUTO_INCREMENT 值不会复用，新插入行会分配下一个 ID（除非显式指定）
- 如果只想更新部分字段，又不想丢失未列出字段的当前值，
REPLACE INTO不适用
什么时候该用 REPLACE INTO 而不是 INSERT ... ON DUPLICATE KEY UPDATE
当业务逻辑明确要求“旧数据必须彻底清除再重建”时才考虑 REPLACE INTO。例如缓存表、物化视图快照、配置项全量覆盖等场景——你不在乎历史痕迹，只要最终状态一致。
而绝大多数“存在则更新”的需求，应该用 INSERT ... ON DUPLICATE KEY UPDATE。它不删除原行，只修改指定列，性能更好，也不会干扰依赖该行的外键或触发器逻辑。
-
REPLACE INTO在高并发下可能引发锁竞争更剧烈（DELETE + INSERT 涉及更多索引维护） -
ON DUPLICATE KEY UPDATE支持引用原值，比如counter = counter + 1；REPLACE INTO只能靠 VALUES 重写全部字段 - MySQL 8.0+ 对
ON DUPLICATE KEY UPDATE优化更好，执行计划更稳定
REPLACE INTO 的字段顺序和默认值陷阱
REPLACE INTO 严格按列定义顺序填充缺失字段，而不是按 VALUES 中的位置推断。如果省略非空且无默认值的列，会直接报错 Field 'xxx' doesn't have a default value。
更隐蔽的问题是：当某列有默认值（比如 created_at DATETIME DEFAULT CURRENT_TIMESTAMP），在 REPLACE INTO 中未显式提供该列，MySQL 会用默认值（即当前时间），而不是保留原值——这和 UPDATE 行为完全不同。
- 务必显式写出所有需要保留原值的字段，哪怕只是重复原值（如
created_at = VALUES(created_at)配合ON DUPLICATE KEY UPDATE才能保留） -
REPLACE INTO不支持SET语法，只能用列名列表 + VALUES，灵活性低于INSERT ... ON DUPLICATE KEY UPDATE - 如果表结构含生成列（generated column），需确认其依赖字段是否在 VALUES 中提供，否则可能触发计算错误
用 EXPLAIN 验证 REPLACE INTO 实际执行路径
别假设 MySQL 一定走“查找→删除→插入”流程。加个 EXPLAIN 能看出真实行为：
EXPLAIN REPLACE INTO users (id, name) VALUES (1, 'Alice');
结果中如果 Extra 列出现 Using where; Using index，说明命中了唯一索引查找；但如果显示 Using temporary; Using filesort，可能意味着没有可用唯一索引，退化成全表扫描+逐行比对，性能极差。
- 确保
REPLACE INTO语句中的匹配条件字段（主键或唯一键）已建索引，否则可能锁表 - 批量操作时，
REPLACE INTO多行 VALUES 仍是一条语句，但内部仍是逐行 DELETE+INSERT，不是原子性批量替换 - 从 MySQL 5.7 升级到 8.0 后，某些字符集或排序规则变更可能导致原本匹配的唯一键失效，让
REPLACE INTO变成纯插入
REPLACE INTO 的情况比想象中少。多数所谓“简化更新”的需求，背后其实是没理清“覆盖”和“修正”的区别——前者要清旧立新，后者只需局部调整。把逻辑想清楚，比选对语法更重要。 
