REPLACE INTO 要求表有主键或唯一索引，否则退化为普通 INSERT；其本质是 DELETE + INSERT，会导致自增 ID 跳变、触发器执行两次、外键约束失败、默认值重置；推荐用 ON DUPLICATE KEY UPDATE 替代，更安全且语义清晰。
REPLACE INTO 要求表有主键或唯一索引
没有主键或唯一索引的表上执行 REPLACE INTO，它就退化成普通 INSERT INTO，不会触发任何“替换”逻辑，反而可能造成重复数据。这是最常被忽略的前提条件。
常见错误现象：执行后发现多条相同业务主键（如 topic+partition+groupid）的记录并存，查表发现表结构里漏建了 UNIQUE KEY (topic, partition, groupid)。
- 必须显式定义主键（
PRIMARY KEY）或至少一个唯一索引（UNIQUE KEY） - 复合唯一索引也有效，比如
UNIQUE KEY uk_topic_pg (topic, partition, groupid) - 仅靠应用层“认为唯一”没用，MySQL 不会自动识别业务唯一性
REPLACE INTO 实际执行的是 DELETE + INSERT
它不是原地更新，而是先删后插。这意味着：
-
AUTO_INCREMENT值会跳变：即使只改一个字段，自增 ID 也会 +1（比如原 ID=5 的记录被替换后，新记录 ID 可能变成 8） - 触发器会触发两次：
BEFORE DELETE和AFTER INSERT，而非一次UPDATE - 外键约束可能失败：若该行被其他表通过外键引用，
REPLACE INTO会因删除阶段违反约束而报错Cannot delete or update a parent row - 默认值会被重置：未在
VALUES中显式指定的字段，将使用列定义的DEFAULT值，而不是保留原值
ON DUPLICATE KEY UPDATE 是更安全的替代方案
绝大多数场景下，应该优先用 INSERT ... ON DUPLICATE KEY UPDATE，原因很实在：
- 不改变自增 ID：冲突时只做原地更新，
AUTO_INCREMENT计数器不动 - 保留未指定字段的原始值：比如只更新
offset，update_time字段不会被设为CURRENT_TIMESTAMP或NULL - 兼容外键：不触发删除动作，绕过外键约束问题
- 语义清晰：明确表达“存在则更新部分字段”，而非隐含的删插语义
示例：INSERT INTO t_offset (topic, partition, groupid, offset) VALUES (?, ?, ?, ?) ON DUPLICATE KEY UPDATE offset = VALUES(offset), update_time = NOW();
批量 REPLACE INTO 的影响行数容易误判
返回的“影响行数”不是“更新了几条”，而是“DELETE 行数 + INSERT 行数”。比如一条冲突记录，返回值是 2；三条冲突，返回值是 6。
这会导致监控或日志中误以为操作量翻倍，尤其在同步任务里容易掩盖真实吞吐瓶颈。
- 单条语句插入 100 行，其中 30 行冲突 → 影响行数 = 30（删） + 100（插） = 130
- 无法直接区分哪些是新增、哪些是覆盖，需额外查表确认
- 如果依赖影响行数做幂等判断（比如“影响 0 行=无变更”），会出错 —— 实际只要插入成功，最少也是 1 行
真正难处理的从来不是语法怎么写，而是删插模型对自增、外键、默认值和监控指标的连锁扰动。用之前，先看表结构和上下游约束是否扛得住。
