INSERT IGNORE将唯一键冲突转为警告并继续执行，但会静默忽略其他错误；ON DUPLICATE KEY UPDATE在冲突时执行指定更新，更安全可控；REPLACE INTO则先删后插，开销大且易引发外键、自增ID等问题。
Insert Ignore 为什么能跳过唯一键冲突
INSERT IGNORE 的本质是把唯一键冲突（ERROR 1062: Duplicate entry）当作警告（warning）处理，语句继续执行但不报错。它适合你明确知道重复数据可直接丢弃的场景，比如日志去重、缓存预热批量插入。
注意：INSERT IGNORE 不仅忽略唯一键冲突，还会静默吞掉其他错误，比如字段类型不匹配、NOT NULL 字段插入 NULL —— 这些也会变成 warning 而非 error，容易掩盖真实问题。
实操建议：
- 只在目标表有且仅有唯一约束（或主键）需要忽略时使用，避免误吞其他异常
- 执行后务必检查
mysql_affected_rows()或ROW_COUNT()：返回 0 表示被忽略，1 表示成功插入，-1 才是真正出错 - 不要依赖
SHOW WARNINGS做逻辑判断——warning 可能被后续语句覆盖，也不稳定
On Duplicate Key Update 怎么安全更新已有记录
ON DUPLICATE KEY UPDATE 是更可控的选择：当冲突发生时，执行指定的更新操作，而不是丢弃整行。它要求你明确写出哪些字段要更新，且只能作用于触发冲突的那个唯一键对应的行。
常见误用是写成 ON DUPLICATE KEY UPDATE id = id 这种无意义更新，或者漏掉 WHERE 条件导致意外覆盖其他字段。
实操建议：
- 更新字段必须是表中真实存在的列，不能引用 VALUES() 以外的外部变量（如子查询结果）
- 如果想保留原值，显式写
col = col；想用新值就写col = VALUES(col)—— 注意VALUES(col)指的是本次 INSERT 中该列的值，不是函数调用 - 慎用
ON DUPLICATE KEY UPDATE created_at = NOW()类逻辑：若业务依赖created_at表示首次插入时间，这种写法会让它变成每次冲突都刷新，失去语义
Replace Into 和前两者的关键区别在哪
REPLACE INTO 看似类似，但行为完全不同：它先尝试 INSERT，冲突时**先 DELETE 原有行，再 INSERT 新行**。这会引发几个隐性问题：
外键约束可能被触发（如果关联表设了 ON DELETE CASCADE）；自增 ID 会变化；触发器会执行两次（DELETE + INSERT 各一次）；而且 DELETE + INSERT 的开销明显高于 UPDATE。
实操建议：
- 除非你确实需要重置整行（包括清空未在 INSERT 列表中出现的字段），否则不要用
REPLACE INTO - 它无法做“部分更新”，所有未列出的字段都会被设为默认值或 NULL，极易造成数据丢失
- 在高并发下，DELETE + INSERT 组合更容易引发锁等待甚至死锁，比
ON DUPLICATE KEY UPDATE更重
批量插入时怎么选才不踩坑
批量 INSERT 配合 IGNORE 或 ON DUPLICATE KEY UPDATE 很常见，但要注意 MySQL 的“语句原子性”边界：整条 INSERT 语句要么全成功，要么在遇到第一个不可恢复错误时中断（比如主键冲突之外的语法错误），而唯一键冲突本身不会中断语句执行。
容易被忽略的一点是：批量中某一行触发冲突，不影响后续行处理 —— 但如果你用了 REPLACE INTO，DELETE 动作可能让后续行的唯一键计算结果发生变化（尤其涉及组合唯一索引时），导致行为难以预测。
实操建议：
- 批量插入超过 1000 行时，拆成多个语句（比如每 500 行一批），降低单语句锁持有时间和内存压力
- 不要在事务里塞超大批次 +
ON DUPLICATE KEY UPDATE：UPDATE 操作会加行锁，容易拖慢并发写入 - 如果业务允许，优先用
INSERT ... SELECT ... ON DUPLICATE KEY UPDATE替代应用层循环，减少网络往返和客户端逻辑复杂度
实际用哪个，取决于你对“冲突”的定义：是彻底不要重复数据（INSERT IGNORE），还是想合并更新（ON DUPLICATE KEY UPDATE），又或者真需要重建整行（极少情况才用 REPLACE INTO）。别为了省几行代码选错语义。
