INSERT IGNORE仅在违反PRIMARY KEY或UNIQUE约束时静默跳过，其他错误（如字段超长、NOT NULL插NULL）仍报错；需预先建唯一索引，多值插入按行判断，返回affected rows为实际新增数，不回滚已成功行，无UPDATE能力。
INSERT IGNORE 什么情况下真正生效
它只对违反 PRIMARY KEY 或 UNIQUE 约束的错误静默跳过，其他任何问题照常报错。比如字段超长、类型不匹配、NOT NULL 插入 NULL，这些都不会被忽略。
常见误判：表里没建唯一索引，却指望 INSERT IGNORE 起作用——结果和普通 INSERT 完全一样，该报错还报错。
- 必须提前在目标列上定义
PRIMARY KEY或UNIQUE KEY - 多个唯一索引时，只要命中任意一个，该行就被忽略
- MySQL 5.7+ 开启
STRICT_TRANS_TABLES后，部分隐式转换冲突仍会中断执行
批量插入时的逐行行为容易被误解
INSERT IGNORE 对多值语句是按行判断的，不是“整批原子失败”。第一行冲突被跳过，后面几行只要不冲突，照样插入成功。
示例：INSERT IGNORE INTO users (id, name) VALUES (1,'a'), (2,'b'), (1,'c'); —— 第 1 行和第 3 行 id=1 冲突，但第 2 行仍会插入。
- 返回的
affected rows是实际新增行数（如上例返回 1） - 不会回滚前面已成功的行，事务中混用需手动控制边界
- 用
SHOW WARNINGS可查到被忽略的具体原因，比如Duplicate entry '1' for key 'PRIMARY'
为什么 INSERT IGNORE 后查不到数据却没报错
这是最常踩的坑：语句执行成功，返回 0 行影响，但你以为是网络或逻辑错误，其实是它安静地跳过了。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
尤其在应用层依赖 mysql_affected_rows() 判断成败时，0 可能意味着“已存在”，而非“执行失败”。
- 别靠是否报错来判断是否插入成功，得看返回的受影响行数
- 日志里默认看不到 warning，除非显式调用
SHOW WARNINGS或开启 general_log - 监控系统若只捕获 error 级别日志，这类跳过完全不可见
INSERT IGNORE 不等于幂等更新
它只做“有就跳过”，不做“有就改”。想更新已有记录的某些字段，INSERT IGNORE 无能为力，语法也不允许跟 UPDATE 子句。
比如要插入用户，但若已存在则更新 last_login 时间戳，必须换用 INSERT ... ON DUPLICATE KEY UPDATE。
-
REPLACE INTO更危险：先删后插，自增 ID 重置、触发器执行两次、外键关联可能断裂 -
INSERT IGNORE是三者中最轻量、最安全的，但也最“被动” - 真正需要“存在则更新”逻辑时，硬套
INSERT IGNORE会导致业务字段长期 stale
实际写法里最容易被忽略的一点：它不提供任何上下文反馈——既不告诉你哪一行被跳了，也不说明跳了多少次。你得自己加监控、查 warning、比对输入输出，否则数据静默丢失都发现不了。
