REPLACE INTO本质是DELETE+INSERT而非更新，会导致自增ID跳变、触发器重复执行、外键级联风险及时间戳不自动刷新；无主键或唯一索引时等同于普通INSERT；多唯一键冲突可能误删多行；日常业务应优先选用更安全可控的INSERT ON DUPLICATE KEY UPDATE。
REPLACE INTO 会先删后插，不是真更新
它不是在原记录上修改字段，而是执行 DELETE + INSERT 两步操作。这意味着：自增主键会跳变、触发器会触发两次（DELETE 和 INSERT 各一次）、外键约束可能被短暂中断、ON UPDATE CURRENT_TIMESTAMP 字段不会自动刷新（因为是新插入的行）。
必须有主键或唯一索引才能生效
如果表没定义任何 PRIMARY KEY 或 UNIQUE 约束，REPLACE INTO 就等价于普通 INSERT INTO，重复数据照插不误。
- 只存在主键冲突 → 删除旧行，插入新行，
AUTO_INCREMENT值递增 - 只存在唯一索引冲突 → 同样删除再插，
AUTO_INCREMENT仍会+1 - 同时触发多个唯一键冲突（比如一条数据撞上两个
UNIQUE索引）→ MySQL 会删掉所有匹配的行（可能不止一条！），再插入新行，影响行数 = 删除数 + 插入数
批量 REPLACE INTO 的坑：ID 重置和时间戳丢失
用 REPLACE INTO table SELECT ... 批量覆盖时，常见问题包括：
-
id字段（自增主键）全部变成新值，原有顺序和连续性彻底丢失 -
created_at被重写为当前时间，但updated_at不会自动更新（除非显式赋值） - 如果表有
NOT NULL DEFAULT字段且未在REPLACE中指定，会被设为默认值，覆盖原有数据 - 并发写入时，
REPLACE的 delete-insert 非原子中间态可能导致短暂数据不可见
为什么通常该用 ON DUPLICATE KEY UPDATE 而不是 REPLACE INTO
绝大多数 Upsert 场景下，ON DUPLICATE KEY UPDATE 更安全、更可控：
- 不改变主键值，
AUTO_INCREMENT不无故递增 - 可精确控制哪些字段更新（用
VALUES(column)引用新值，或保留原值） - 不会意外删掉多条记录（
REPLACE在多唯一键场景下行为难预测） -
ON UPDATE CURRENT_TIMESTAMP对应字段能正常触发
只有当你明确需要“彻底替换整行”且接受 ID 变更、时间戳重置等副作用时，才考虑 REPLACE INTO。日常业务逻辑中，它比看起来危险得多。
