REPLACE INTO 是先删后插而非更新，会导致自增ID跳变、触发器执行两次、外键级联异常；需有主键或唯一索引才生效，否则退化为普通INSERT；未指定字段会被置为默认值；主从复制和事务中存在一致性风险，应优先使用 INSERT ... ON DUPLICATE KEY UPDATE。
REPLACE INTO 为什么不是 INSERT ON DUPLICATE KEY UPDATE
因为 REPLACE INTO 本质是“删再插”，不是“更新”。只要主键或唯一索引冲突，它就先 DELETE 原有行，再 INSERT 新行。这意味着自增 ID 会跳变、触发器会执行两次（DELETE + INSERT）、外键级联动作可能被意外触发。
常见错误现象：REPLACE INTO 后发现 id 变大了，但数据看起来“对”；或者依赖 AFTER INSERT 触发器的逻辑出错，因为实际发生了 DELETE + INSERT。
- 使用场景：仅当你明确需要“完全替换整行”，且不介意 ID 变化、触发器重复执行时才用
- 性能影响：比
INSERT ... ON DUPLICATE KEY UPDATE多一次索引查找和一次 DELETE 操作 - 兼容性：MySQL 支持，但 MariaDB 8.0+ 默认禁用
REPLACE权限；PostgreSQL、SQLite 完全不支持
REPLACE INTO 的主键/唯一约束必须存在
没有主键或唯一索引的表上执行 REPLACE INTO，行为等同于普通 INSERT —— 不会触发任何替换逻辑，也不会报错。这是最容易忽略的前提条件。
常见错误现象：执行完 REPLACE INTO users (name, email) VALUES ('Alice', 'a@b.com')，发现重复数据依然插入成功，查表才发现 email 字段没建 UNIQUE 索引。
- 必须确保至少一个列（或列组合）有
PRIMARY KEY或UNIQUE约束 - 检查方式：
SHOW CREATE TABLE users;，确认输出里含UNIQUE KEY或PRIMARY KEY - 如果想按业务字段（如
email）去重，必须显式加UNIQUE(email)，不能只靠应用层保证
REPLACE INTO 会清空未指定字段的值
REPLACE INTO 是完整行替换，所有未在 VALUES 或 SELECT 中显式给出的字段，都会被设为默认值（或 NULL），而不是保留原值。
常见错误现象：原记录 status = 'active'、updated_at = '2024-01-01'，但只写 REPLACE INTO users (id, name) VALUES (1, 'Bob')，结果 status 变成 NULL，updated_at 也丢了。
- 如果只想改部分字段，必须写出所有要保留的字段（哪怕值不变）
- 更安全的做法是改用
INSERT ... ON DUPLICATE KEY UPDATE status = VALUES(status), updated_at = NOW() - 注意
VALUES(col)在ON DUPLICATE KEY UPDATE中表示“本次 INSERT 中该列的值”，不是函数调用
REPLACE INTO 和事务、复制的安全边界
在开启 binlog 的 MySQL 主从环境中，REPLACE INTO 产生的 DELETE + INSERT 事件会被分别记录。如果从库延迟或中断过，可能造成主从不一致 —— 尤其当 DELETE 被同步了，但后续 INSERT 因网络问题丢失。
另外，在事务中使用 REPLACE INTO，若中途回滚，DELETE 已发生，但回滚会把它“恢复”回来；看起来没问题，但如果你依赖 LAST_INSERT_ID()，它返回的是新插入行的 ID，而旧行已被删过一次。
- 高一致性要求场景（如金融、订单）应避免
REPLACE INTO，优先用带条件判断的INSERT ... ON DUPLICATE KEY UPDATE - 如果必须用，确保 binlog_format = ROW（而非 STATEMENT），减少复制风险
- 不要依赖
REPLACE INTO返回的LAST_INSERT_ID()做关键业务判断——它不可靠
