replace into 的实际执行逻辑是先尝试插入，若主键或唯一索引冲突则先删除旧行再插入新行，导致自增id变化、触发器执行两次、未指定字段重置为默认值。
REPLACE INTO 不是“避免失败”的兜底方案，而是“先删后插”的暴力覆盖——用错会丢数据，主键或唯一键冲突时它直接删除旧行再插入新行。
REPLACE INTO 的实际执行逻辑是什么？
MySQL 执行 REPLACE INTO 时，并不会跳过冲突或更新字段，而是按以下顺序操作：
- 尝试插入新行；
- 如果遇到主键（
PRIMARY KEY）或唯一索引（UNIQUE）冲突，就先执行DELETE删除已有冲突行； - 再执行
INSERT插入当前语句中的全部字段值（未显式指定的列按默认值或NULL处理）。
这意味着：哪怕你只想更新某几个字段，REPLACE INTO 也会把其他列重置为默认值（比如 created_at 被设为 0000-00-00 00:00:00 或当前时间，取决于定义），而不是保留原值。
和 INSERT ... ON DUPLICATE KEY UPDATE 的关键区别
这是最容易混淆也最危险的一点：REPLACE INTO 和 INSERT ... ON DUPLICATE KEY UPDATE 表面目标相似，但行为完全不同：
-
REPLACE INTO是DELETE + INSERT，自增 ID 会变化，触发器会触发两次（DELETE和INSERT各一次），外键级联动作可能被意外触发； -
INSERT ... ON DUPLICATE KEY UPDATE是原地更新，只影响指定字段，自增 ID 不变，只触发一次INSERT触发器（或UPDATE触发器，取决于 MySQL 版本和触发器定义）； - 若表有多个唯一索引，
REPLACE INTO只要任一索引冲突就会删行；而ON DUPLICATE KEY UPDATE只对第一个匹配的唯一冲突生效（按索引创建顺序），其余冲突不处理（可能报错，取决于 SQL 模式）。
示例：假设 users(id PK, email UNIQUE, phone UNIQUE)，现有行 (1, 'a@b.com', '123')。执行 REPLACE INTO users (email, phone) VALUES ('a@b.com', '456') —— 会删掉 id=1 的整行，再插入新行，新行 id 变成下一个自增值（如 2），email 和 phone 更新了，但 created_at、updated_at 等未指定字段全按默认值来。
什么场景下才该谨慎用 REPLACE INTO？
仅在满足以下全部条件时可考虑：
- 你明确需要“完全替换”整行，而非局部更新；
- 表没有外键约束，或你已确认级联删除/插入是预期行为；
- 自增主键变化不影响业务（比如 ID 不暴露给前端、不作为日志关联依据）；
- 你控制着所有写入路径，且能确保不会因并发导致“删-插”窗口期丢失数据（例如 A 删、B 查不到、A 插，B 再删…）；
- 你已测试过触发器行为，确认双触发符合逻辑（比如审计日志会记两条）。
常见误用：用它来“upsert 用户资料”，结果把 created_at 改成当前时间，或把软删除标记 is_deleted=1 重置为 0。
替代方案推荐：优先用 INSERT ... ON DUPLICATE KEY UPDATE
绝大多数所谓“避免主键冲突插入失败”的需求，真正该用的是：
INSERT INTO users (id, name, email, updated_at) VALUES (1, 'Alice', 'alice@example.com', NOW()) ON DUPLICATE KEY UPDATE name = VALUES(name), email = VALUES(email), updated_at = VALUES(updated_at);
这样只更新指定字段，保留原 created_at、is_deleted 等不变。注意：VALUES(col) 引用的是本次 INSERT 中该列的值，不是原行值。
如果你连主键都不确定是否存在，又不想写两步（先查再决定 insert/update），那就得接受 REPLACE INTO 的副作用——它不是银弹，只是个带代价的覆盖开关。
