replace into 本质是“删再插”，即先删除冲突行再插入新行，导致自增id变化、触发器执行两次、非指定字段被重置为默认值或null。
REPLACE INTO 本质是“删再插”，不是 UPDATE
MySQL 的 REPLACE INTO 不是原地更新，而是先尝试插入，遇到主键（PRIMARY KEY）或唯一索引（UNIQUE）冲突时，自动删除已有行，再插入新行。这意味着：自增 ID 可能变化、触发器会执行两次（DELETE + INSERT）、外键约束可能被触发、原有行的其他列值（没在语句中指定的）会被清空为默认值或 NULL。
常见错误现象：REPLACE INTO users (id, name) VALUES (1, 'Alice') 执行后，email 列变成 NULL —— 因为原记录被删了，新插入只设了 id 和 name，其余字段按表定义取默认值。
- 仅适用于有明确主键或唯一索引约束的表，否则等同于普通
INSERT - 不支持
ON DUPLICATE KEY UPDATE那样的条件更新逻辑 - 如果表有多个唯一索引，只要任一索引冲突就会触发替换
什么时候该用 REPLACE INTO 而不是 INSERT ... ON DUPLICATE KEY UPDATE
真正适合 REPLACE INTO 的场景极少：只有当你明确需要“覆盖整行”且能接受 ID 重置、触发器双触发、非目标字段被重置时才考虑。典型例子是缓存表、日志快照表、或某些幂等写入的中间表，其中数据完整性要求宽松，且结构简单（比如只有主键 + 几个字段，无外键依赖）。
绝大多数业务场景下，INSERT ... ON DUPLICATE KEY UPDATE 更安全可控——它保留原记录的未指定字段值，只更新你列出的列，也不会改变自增 ID。
- 想保留
created_at时间戳？REPLACE INTO会把它重置为当前时间（除非显式赋值），而ON DUPLICATE KEY UPDATE可以跳过它 - 表有
updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP？REPLACE INTO触发的是新 INSERT，updated_at会被设为当前时间；但如果你只想在真正更新时才改它，就得用后者并显式写updated_at = VALUES(updated_at) - 性能上，
REPLACE INTO多一次 DELETE 操作，IO 开销略高
REPLACE INTO 的语法和参数限制
REPLACE INTO 支持 VALUES、SET 和 SELECT 三种写法，但行为一致：冲突即删再插。
示例：REPLACE INTO products (sku, price, stock) VALUES ('ABC-123', 99.9, 10)；或 REPLACE INTO products SET sku='ABC-123', price=99.9, stock=10；或 REPLACE INTO products SELECT sku, price, stock FROM temp_import WHERE sku IS NOT NULL。
- 不能在
REPLACE INTO ... SELECT中使用子查询引用目标表本身（会报ERROR 1093），需用派生表绕过 - 批量替换时，每行独立判断冲突，不支持跨行去重逻辑
- 没有事务原子性保障以外的额外锁机制，高并发下仍需注意间隙锁（gap lock）行为
容易忽略的坑：自增 ID 跳变与 binlog 格式影响
执行 REPLACE INTO 后，即使只是“逻辑上更新”，自增 ID 也会递增——因为底层是先 DELETE 再 INSERT，而 INSERT 会申请新 ID。这会导致 ID 不连续，对某些依赖 ID 序列的应用（如分页、归档逻辑）造成干扰。
更隐蔽的问题在主从复制中：如果 binlog_format 是 STATEMENT，REPLACE INTO 在从库重放时可能因执行顺序不同导致结果不一致；ROW 格式虽能保证数据一致，但日志体积更大，且从库无法感知“本意是更新”还是“真的要删再插”。
- 监控时发现自增 ID 突然跳了很多？先查是否有
REPLACE INTO批量导入任务 - 用
SHOW ENGINE INNODB STATUS查近期死锁时，注意REPLACE引起的锁等待可能比UPDATE更长 - 线上表结构变更（比如新增唯一索引）后，原来正常的
REPLACE INTO可能突然开始误删数据——因为它现在匹配到了新的唯一约束
REPLACE INTO。
