REPLACE INTO 本质是“先删后插”，非真正更新：遇主键或唯一索引冲突时删除原行再插入新行，不保留原字段值、不触发UPDATE触发器、导致自增ID重分配、外键RESTRICT下会报错；仅适用于需完全替换整行且无依赖风险的极少数场景。
REPLACE INTO 本质是「删 + 插」，不是 UPDATE
MySQL 的 REPLACE INTO 看似像“存在则更新，不存在则插入”，但实际执行逻辑完全不同：它先尝试插入，若遇到主键（PRIMARY KEY）或唯一索引（UNIQUE）冲突，则**先删除已存在的行，再插入新行**。这意味着它不保留原记录的其他字段值，也不触发 UPDATE 相关的触发器或自增 ID 复用行为。
常见误用场景：想只更新部分字段（如只改 status），却用 REPLACE INTO，结果把没显式指定的字段（比如 created_at、updated_at）重置为默认值或 NULL。
- 如果表有
AUTO_INCREMENT主键，REPLACE INTO会导致 ID 被重新分配（旧行删掉，新行插入），ID 不连续 - 不会调用
BEFORE UPDATE或AFTER UPDATE触发器，只可能触发INSERT类触发器 - 外键约束下，若被引用行存在
ON DELETE RESTRICT，REPLACE INTO会直接报错（因为删操作被拒绝）
什么情况下该用 REPLACE INTO 而不是 INSERT ... ON DUPLICATE KEY UPDATE
真正适合 REPLACE INTO 的场景极少，仅当满足以下全部条件时才合理：
- 你明确需要「完全替换整行」，而非局部更新
- 表无重要依赖（如外键
RESTRICT或级联删除风险） - 自增 ID 是否变化对你无影响（例如日志类、缓存类表）
- 你控制着所有字段值，且能确保未列出的字段在
INSERT中有安全默认值（如NOT NULL DEFAULT CURRENT_TIMESTAMP）
绝大多数业务场景（如用户资料更新、订单状态变更）应优先使用 INSERT ... ON DUPLICATE KEY UPDATE，它才是真正意义上的“存在即更新”。
REPLACE INTO 的字段缺失会导致隐式重置
REPLACE INTO 是完整行插入语义，任何未在语句中显式给出的字段，都会按其定义的默认值或约束处理——这很容易引发数据丢失。
例如这张表：
CREATE TABLE users ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50) NOT NULL, email VARCHAR(100) UNIQUE, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP );
执行：
REPLACE INTO users (id, name, email) VALUES (1, 'Alice', 'alice@example.com');
结果：created_at 和 updated_at 都会被设为当前时间，原始的创建时间彻底丢失。而如果你本意只是更新邮箱，这个操作就破坏了数据语义。
性能与锁行为比 UPDATE 更重
REPLACE INTO 在冲突时需执行 DELETE + INSERT 两步，涉及更多行锁和索引维护开销：
- 对主键/唯一索引冲突行加
X锁后立即删除，再对新行插入加锁 - 在高并发写入下，比
INSERT ... ON DUPLICATE KEY UPDATE更容易引发死锁（尤其多唯一索引时） - Binlog 中记录为两个事件（
Delete_rows_event+Write_rows_event），复制延迟和审计难度更高
如果只是更新一两个字段，用 REPLACE INTO 就像用推土机修指甲——力气大，但不对路。
真正要小心的是：很多人以为 REPLACE INTO 是 MySQL 的“UPSERT”，但它的行为边界非常窄；一旦表结构含时间戳、计数器、JSON 默认值或外键约束，它就极可能悄悄破坏数据一致性。动手前，先确认你是不是真的需要删掉那行再重建一次。
