INSERT IGNORE仅跳过主键或唯一键冲突并转为警告，其他错误（如NOT NULL违例、类型不匹配）仍报错中断；ON DUPLICATE KEY UPDATE在冲突时执行指定更新，更安全可控；REPLACE INTO先删后插，引发自增ID跳变、外键级联等副作用；无唯一索引时只能用INSERT ... SELECT ... WHERE NOT EXISTS兜底，但性能差且存在竞态风险。
INSERT IGNORE 只跳过主键/唯一键冲突，其他错误照常报错
INSERT IGNORE 不是“忽略所有错误”，它只对违反 PRIMARY KEY 或 UNIQUE 约束的插入行为降级为警告，其余问题（如 NOT NULL 字段为空、字段类型不匹配、超出长度限制、外键约束失败）依然会抛出错误并中断执行。
常见现象：Duplicate entry '123' for key 'PRIMARY' 不再报错，但 mysql_affected_rows() 返回 0；用 SHOW WARNINGS 能看到被跳过的具体行。
- 必须提前建好主键或唯一索引，否则
INSERT IGNORE和普通INSERT行为完全一样 - 事务中被忽略的语句仍计入执行序列，不会回滚，但会影响
LAST_INSERT_ID() - 批量插入时，只要某一行触发非唯一性错误（比如字符串超长），整条
INSERT语句就会失败——IGNORE对这类错误无效
ON DUPLICATE KEY UPDATE 更精准，但不支持批量字段映射
当你需要“存在则更新某些字段”时，INSERT ... ON DUPLICATE KEY UPDATE 是语义最清晰的选择。它只在发生主键或唯一键冲突时执行指定的 UPDATE 子句，其余情况照常插入。
示例：INSERT INTO users (id, name, updated_at) VALUES (123, 'Alice', NOW()) ON DUPLICATE KEY UPDATE name = VALUES(name), updated_at = NOW();
-
VALUES(col)引用的是本次INSERT中该列的值，不是原记录当前值 - 如果表有多个唯一索引（如
UNIQUE KEY uk_email (email)和UNIQUE KEY uk_phone (phone)），冲突只会触发一次UPDATE，需确保逻辑覆盖所有可能冲突路径 - MySQL 8.0.21+ 支持
ON DUPLICATE KEY UPDATE DO NOTHING，等效于无副作用的跳过 - 注意：该语法不支持在批量
VALUES中为每行指定不同更新逻辑，所有行共用同一套UPDATE表达式
REPLACE INTO 会删再插，副作用明显
REPLACE INTO 看似能“覆盖重复”，但底层是先 DELETE 再 INSERT，这会带来一连串连锁反应：
- 自增
id值可能变化（旧行删除后新行获得新id） - 触发
BEFORE/AFTER DELETE和BEFORE/AFTER INSERT触发器 - 若外键设了
ON DELETE CASCADE，关联数据可能被意外清除 - 对于大表，频繁删插影响性能，且锁粒度更大（涉及 delete + insert 两阶段）
除非你明确需要重置自增 ID 或强制刷新整行状态，否则不推荐用 REPLACE INTO 替代 INSERT IGNORE 或 ON DUPLICATE KEY UPDATE。
没有唯一索引时，只能靠子查询兜底
如果表没设主键或唯一索引，INSERT IGNORE、ON DUPLICATE KEY UPDATE、REPLACE INTO 全部失效。此时唯一办法是用 INSERT ... SELECT ... WHERE NOT EXISTS 手动判断：
INSERT INTO user (name, role) SELECT '张三', 'admin' FROM DUAL WHERE NOT EXISTS (SELECT 1 FROM user WHERE name = '张三' AND role = 'admin');
- 性能差：每插一行都执行一次子查询，大数据量下 I/O 和 CPU 开销显著上升
- 并发安全弱：
NOT EXISTS到实际插入之间存在竞态窗口，高并发时仍可能写入重复 - 必须搭配
SELECT ... FROM DUAL（MySQL 8.0+ 可省略FROM DUAL），不能直接写VALUES
真正可靠的去重，永远始于建好 UNIQUE INDEX 或 PRIMARY KEY——这是所有方案生效的前提，也是最容易被跳过的一步。
