insert on duplicate key update是首选方案，只要表上有primary key或unique索引，就能原子执行“存在则更新、不存在则插入”，不删行、不改主键、不触发外键级联或重复触发器；若无对应索引，该语法退化为普通insert并报错。
INSERT ON DUPLICATE KEY UPDATE 是首选方案
只要表上有 PRIMARY KEY 或 UNIQUE 索引，INSERT ... ON DUPLICATE KEY UPDATE 就能安全、原子地完成“存在则更新，不存在则插入”。它不删除旧行，只修改指定字段，避免了主键变更、外键级联、触发器误触发等副作用。
常见错误是没建索引就用这个语法——MySQL 根本不会触发 ON DUPLICATE KEY UPDATE，而是当作普通 INSERT 执行，重复时直接报错 Duplicate entry 'xxx' for key 'xxx'。
- 必须确保目标字段（如
email、order_no）已建UNIQUE索引，不能仅靠应用层判断 - 更新部分用
VALUES(col_name)引用 INSERT 子句中的值，而不是写死常量，否则容易覆盖为默认值 - 若需更新时间戳，推荐写成
updated_at = VALUES(updated_at)或updated_at = NOW()，后者更可控
REPLACE INTO 适合全量替换但有隐性成本
REPLACE INTO 表面看是“插入或替换”，实际执行逻辑是：先 DELETE 再 INSERT。这意味着它会生成两条 binlog 记录、触发两次触发器、重置自增 ID（如果被删行的 ID 是当前最大值）、且可能破坏外键引用完整性。
它只在你明确需要“完全丢弃旧数据、用新数据重建整行”时才合理，比如缓存表、配置快照表。日常业务表慎用。
- 返回值是受影响行数之和（1 行表示纯插入，2+ 行表示发生了删除+插入）
- 如果表没有
PRIMARY KEY或UNIQUE索引，REPLACE INTO等价于INSERT INTO，失去意义 - 在主从复制中，
REPLACE的 DELETE+INSERT 模式可能放大延迟，尤其大表
INSERT IGNORE 只适合“跳过即结束”的场景
INSERT IGNORE 的作用就是静默忽略冲突，不报错、不更新、不返回警告（仅 log 中有 warning）。它适合日志采集、埋点上报这类“丢了也不影响核心逻辑”的弱一致性写入。
但它无法表达“我本来想更新某些字段”的意图。一旦用了 IGNORE，你就放弃了对重复情况的任何响应能力——既不能记录冲突次数，也不能 fallback 到更新逻辑。
- 遇到唯一冲突时，
INSERT IGNORE返回0 rows affected，可用于简单幂等判断 - 它不会阻止其他非唯一约束错误（如 NOT NULL 违反），那些仍会报错
- 注意：MySQL 8.0 默认 warning 被抑制，需开
sql_mode=STRICT_TRANS_TABLES或查SHOW WARNINGS才能看到忽略细节
别忘了唯一索引才是前提，不是可选项
所有“防重复插入”语法都依赖底层索引机制。没有 UNIQUE 或 PRIMARY KEY，它们全失效。很多人卡在这一步：建了表、写了语句、反复报错，最后发现只是忘了加索引。
加索引不是加完就完事。要确认业务语义是否匹配：UNIQUE(email) 允许多个 NULL，而 PRIMARY KEY(email) 不允许 NULL；复合唯一索引 UNIQUE(user_id, event_type) 和单字段索引行为完全不同。
- 建索引前先用
SELECT ... GROUP BY ... HAVING COUNT(*) > 1清理现存重复，否则ALTER TABLE ... ADD UNIQUE会失败 - 线上加唯一索引建议用
ALGORITHM=INPLACE（MySQL 5.6+），避免锁表 - 索引字段顺序影响查询效率，也影响
ON DUPLICATE KEY UPDATE是否命中——它只响应定义在索引最左前缀上的冲突
