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 ... 批量覆盖时，常见问题包括：

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

• 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。日常业务逻辑中，它比看起来危险得多。