INSERT IGNORE适用于仅需跳过主键或唯一索引冲突的场景，遇其他错误仍报错；不适用于绕过校验、导入脏数据或替代REPLACE/ON DUPLICATE KEY UPDATE。
INSERT IGNORE 适合什么场景
它只在遇到主键冲突或唯一索引冲突时静默跳过，其他错误（比如字段类型不匹配、NOT NULL 字段插 NULL）照常报错。别指望它兜底所有问题，它不是万能的“容错开关”，而是专治“重复插入”的轻量方案。
常见误用场景：想用它绕过数据校验、批量导入脏数据、替代 REPLACE 或 ON DUPLICATE KEY UPDATE——这些都会踩坑。
和 REPLACE、ON DUPLICATE KEY UPDATE 的关键区别
三者都处理冲突，但行为完全不同：
-
INSERT IGNORE：冲突就丢弃整行，不改已有数据，不触发自增 ID 变化（除非 INSERT 前已生成） -
REPLACE：冲突就先 DELETE 再 INSERT，自增 ID 会+1，可能意外删掉关联数据（比如外键级联没设好） -
ON DUPLICATE KEY UPDATE：冲突时可指定更新哪些字段，更可控，但语法稍长，MySQL 5.6+ 全支持
如果你只想“有就不管，没有才加”，INSERT IGNORE 最干净；如果还想顺手更新时间戳或计数器，必须换 ON DUPLICATE KEY UPDATE。
容易被忽略的陷阱
这些坑不报错，但结果和预期差很远：
- 唯一索引字段允许 NULL？那多个 NULL 值不视为冲突——
INSERT IGNORE会继续插入，可能造成逻辑重复 - 表里有多个唯一约束（比如
email和phone都是 UNIQUE），只要其中任一冲突，整行就被忽略，不会只跳过冲突字段 - 执行后
mysql_affected_rows()或mysqli->affected_rows返回 0 表示“被忽略”，不是“失败”——别拿它当错误判断依据 - 事务中使用时，它仍是原子操作，但不会回滚已成功插入的其他行，需自行控制事务边界
一个安全使用的最小实践
别裸写 INSERT IGNORE，至少带上明确字段名和检查逻辑：
INSERT IGNORE INTO users (id, email, created_at) VALUES (123, 'a@b.com', NOW());
同时建议：
- 确保目标字段（如
email）有明确的UNIQUE约束，而不是靠应用层“我以为它唯一” - 批量插入时，用
INSERT IGNORE比单条循环更高效，但单次不要超 1000 行，避免锁表太久 - 上线前在测试库用真实数据跑一遍，确认冲突行为符合预期——尤其注意 NULL 和空字符串的处理差异
真正难的从来不是语法，而是想清楚：你到底要跳过什么，又绝不允许跳过什么。
