REPLACE INTO 是先删后插而非更新，需主键或唯一索引触发，会重置自增ID、丢失未指定字段值、触发两次触发器；应优先使用 INSERT ... ON DUPLICATE KEY UPDATE。

REPLACE INTO 是 INSERT 的替代写法，但行为完全不同

MySQL 的 REPLACE INTO 不是“带更新逻辑的插入”，而是先尝试插入，若因主键或唯一索引冲突导致失败，则自动执行 DELETE + INSERT。它没有 UPDATE 语句的原子性更新能力，也不会保留未显式指定字段的原值。

基本语法和触发条件

必须存在主键（PRIMARY KEY）或唯一索引（UNIQUE KEY），否则 REPLACE INTO 等同于普通 INSERT INTO，不会触发替换逻辑。

REPLACE INTO users (id, name, email) VALUES (1, 'Alice', 'alice@example.com');

当 id = 1 已存在时，MySQL 会：

• 定位到冲突行（基于主键或任意一个唯一索引）
• 删除该行
• 插入新行

与 INSERT ... ON DUPLICATE KEY UPDATE 的关键区别

这是最常被混淆的点：REPLACE INTO 是“删再插”，而 INSERT ... ON DUPLICATE KEY UPDATE 是“就地更新”。

• REPLACE INTO 会重置自增 ID（如果替换的是主键行）、触发 DELETE 和 INSERT 两个事件、丢失未指定字段的原始值
• ON DUPLICATE KEY UPDATE 只修改指定列，保留其他字段不变，不改变自增值，性能通常更好
• 如果只想更新部分字段，REPLACE INTO 必须显式写出所有列（否则缺失列会被设为默认值或 NULL）

INSERT INTO users (id, name, email) VALUES (1, 'Bob', 'bob@example.com') 
ON DUPLICATE KEY UPDATE name = VALUES(name), email = VALUES(email);

实际使用时容易踩的坑

在生产环境误用 REPLACE INTO 可能引发数据意外丢失或主键跳跃：

• 外键约束下，DELETE 阶段可能违反 ON DELETE RESTRICT，直接报错中断
• 触发器会被触发两次（BEFORE DELETE + BEFORE INSERT），逻辑易失控
• 如果表有时间戳字段如 created_at 设了 DEFAULT CURRENT_TIMESTAMP，REPLACE 会导致其被重置
• 高并发下，REPLACE 的 DELETE+INSERT 间隙可能被其他事务读到“行不存在”的中间状态