replace into 不是避免主键冲突，而是先删后插，导致id跳变、时间戳重置、触发器误执行；应优先用 insert ignore 或 on duplicate key update。
REPLACE INTO 不能“避免”主键冲突报错，它是在冲突发生后执行 DELETE + INSERT 的补救动作；真正避免报错的方案是 INSERT IGNORE 或 ON DUPLICATE KEY UPDATE ——而 REPLACE INTO 本身会引发 ID 跳变、触发器误执行、时间戳重置等副作用，不推荐用于单纯规避错误。
REPLACE INTO 实际触发的是 DELETE + INSERT，不是静默跳过
当你执行 REPLACE INTO users (id, name) VALUES (1, 'Alice') 且 id=1 已存在时，MySQL 不是“忽略冲突”，而是：先按主键或唯一索引定位旧记录 → 执行 DELETE → 再执行 INSERT。这意味着：
- 返回的受影响行数是 2（1 行 delete + 1 行 insert），不是 0 或 1
- 自增 ID 一定会变化：即使你没显式指定
id，新记录也会拿到下一个 AUTO_INCREMENT 值 -
created_at这类设为CURRENT_TIMESTAMP DEFAULT的字段会被重置为当前时间 - 如果表有
BEFORE DELETE或AFTER INSERT触发器，它们都会被触发
为什么你看到“没报错”，其实代价很高
表面上 REPLACE INTO 没抛 ERROR 1062 (23000): Duplicate entry，但它用更隐蔽的方式破坏数据一致性：
- 并发下竞态丢失：A 线程想更新
status，B 线程想更新retry_count，两者都用REPLACE INTO，B 的INSERT可能覆盖 A 刚改的status（因 B 的VALUES里没带status） - 主从 auto_increment 不一致：主库执行多次
REPLACE INTO后AUTO_INCREMENT值变大，但从库 binlog 回放只记录最终结果，auto_increment值可能滞后；主从切换后新主库插入直接报Duplicate entry - 外键级联风险：若其他表通过外键引用该行且设了
ON DELETE CASCADE，REPLACE INTO的DELETE会意外删掉关联数据
真正适合“避免报错”的替代方案
根据你要达成的效果选：
- 只想插入，重复就不管 → 用
INSERT IGNORE INTO：冲突时返回 0 rows affected，不报错也不改数据，但注意它也会忽略非唯一性错误（如NOT NULL字段传了NULL） - 想插入新记录，冲突时只更新部分字段 → 必须用
INSERT ... ON DUPLICATE KEY UPDATE：例如INSERT INTO logs (event_id, msg) VALUES (123, 'done') ON DUPLICATE KEY UPDATE msg = VALUES(msg), updated_at = NOW()，原行 ID 不变、默认值不重置、触发器只执行一次 - 真需要“删旧建新”语义（比如强制刷新缓存行、重置所有默认值）→ 才考虑
REPLACE INTO，但必须确认业务能接受 ID 变化和时间戳重置
容易被忽略的关键前提：唯一约束必须存在
REPLACE INTO 和 ON DUPLICATE KEY UPDATE 都依赖表上至少一个 PRIMARY KEY 或 UNIQUE INDEX。如果只是普通字段重复，它们完全不生效，行为等同于普通 INSERT，照样报错。常见疏漏：
- 误以为
email字段重复就能触发替换，但没给email加UNIQUE索引 - 表有多个唯一索引（如
username和phone），REPLACE INTO可能匹配到非预期的那条旧记录（比如phone冲突但你想按username更新） -
ON DUPLICATE KEY UPDATE中的VALUES(col)引用的是本次INSERT的值，不是原记录值；写成counter = counter + 1是错的，得用counter = IFNULL(counter, 0) + 1
