INSERT IGNORE仅在违反PRIMARY KEY或UNIQUE约束时跳过并转为警告，其他错误（如字段超长、NULL插入NOT NULL列）仍报错中断；必须有对应唯一索引才生效，无索引则完全无效。
INSERT IGNORE 不是万能的“静默跳过”，它只对重复键冲突生效，其他错误（比如字段长度超限、NULL 插入非空列）依然会报错并中断执行。
INSERT IGNORE 什么情况下真正跳过？
它只捕获 ER_DUP_ENTRY 类型的错误（即违反 PRIMARY KEY 或 UNIQUE 约束），并将其转为警告，语句继续执行。其余错误（如 ER_DATA_TOO_LONG、ER_BAD_NULL_ERROR）仍抛出异常。
- 表中已有
email = 'a@b.com'，且email是UNIQUE索引 → 再次INSERT IGNORE同值，不报错，影响行数为 0 - 同一语句中还插入了超长字符串到
VARCHAR(10)字段 → 整条INSERT仍失败，哪怕前面的重复键本可跳过 - 使用
INSERT IGNORE批量插入多行时，只有因唯一键冲突的行被忽略，其余合法行照常插入
和 REPLACE INTO、ON DUPLICATE KEY UPDATE 的关键区别
三者处理重复键逻辑不同，选错可能引发数据丢失或逻辑错误：
-
REPLACE INTO：先DELETE再INSERT，自增 ID 会变，触发器会执行两次，外键约束可能被破坏 -
INSERT ... ON DUPLICATE KEY UPDATE：只更新指定字段，不改变主键，不重置自增计数器，适合“存在则更新”场景 -
INSERT IGNORE：完全跳过整行，不做任何修改，适合“存在则丢弃”场景（如去重导入日志）
例如：INSERT IGNORE INTO users (id, name, email) VALUES (1, 'Alice', 'a@b.com'); 若 id=1 已存在，整行丢弃；而 ON DUPLICATE KEY UPDATE name = VALUES(name) 会保留原 id 并只更新 name。
实际使用时容易踩的坑
看似简单，但几个细节会让结果不符合预期：
- 唯一约束必须是索引 —— 单独在字段上加
UNIQUE约束但没建索引？INSERT IGNORE不生效（MySQL 要求约束由索引支撑） - 联合唯一索引要完全匹配 —— 如
UNIQUE KEY (a,b)，只提供a值的INSERT IGNORE不会触发跳过 - 忽略后无法知道哪一行被跳过了 ——
mysql_affected_rows()返回 0 表示“没插入新行”，但不区分是全跳过还是全失败；需用SHOW WARNINGS查看具体警告信息 - 事务中慎用 —— 如果前一条语句已报错（非重复键），后续
INSERT IGNORE可能因事务状态异常而不执行
替代方案：更可控的“存在则忽略”逻辑
当需要精确控制行为（比如只忽略特定字段冲突、或记录跳过明细），纯靠 INSERT IGNORE 不够用：
- 用
SELECT ... WHERE NOT EXISTS+INSERT两步走，逻辑清晰但性能差，且有竞态风险（需加锁或事务隔离） - 应用层先
SELECT判断再决定是否INSERT，同样有并发问题，适合低频场景 - MySQL 8.0+ 可考虑
INSERT ... ON CONFLICT DO NOTHING（PostgreSQL 风格），但 MySQL 原生不支持，需靠应用封装或中间件模拟
真正稳定的去重写入，往往得结合业务容忍度：能接受少量重复就用 INSERT IGNORE；要求强一致就得引入分布式锁或幂等表设计。
