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 间隙可能被其他事务读到“行不存在”的中间状态
INSERT ... ON DUPLICATE KEY UPDATE；只有明确需要清空旧行并重建（比如缓存表全量刷新）才用 REPLACE INTO。 
