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 会： 定位到冲突行（基于主键或任意一个唯一索引） 删除该行 插入新行 注意：如果表有多个唯一索引，只要任一索引冲突就会触发 REPLACE，不一定是主键。
与 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 间隙可能被其他事务读到“行不存在”的中间状态 真正需要“替换语义”时，优先考虑
INSERT ... ON DUPLICATE KEY UPDATE；只有明确需要清空旧行并重建（比如缓存表全量刷新）才用
REPLACE INTO。
