INSERT IGNORE在触发器中遇主键或唯一索引冲突时静默跳过整行，不报错、不抛异常、ROW_COUNT()返回0，上层无法感知；仍消耗自增ID、加锁不简化、不支持SHOW WARNINGS捕获，且仅抑制错误码1062，其他错误照常中断。
INSERT IGNORE在触发器里会静默丢掉整行，且无法被上层感知
触发器中执行 INSERT IGNORE 时，若遇到主键或唯一索引冲突，语句直接跳过、不报错、不抛异常，但也不会返回任何失败信号。上层事务或调用方完全不知道这一行“本该插入却没插成”，ROW_COUNT() 返回 0，而触发器本身又不能 throw 错误中断流程——结果就是数据丢失无声无息。
常见错误现象：用户注册成功后，触发器试图往日志表写一条记录，但日志表的 event_id 是唯一索引且已存在，INSERT IGNORE 静默跳过，日志缺失，后续排查毫无线索。
- 触发器内无法用
SHOW WARNINGS捕获警告（语法不支持） -
GET DIAGNOSTICS在大多数 MySQL 版本中对触发器内警告不可见 - 即使外层事务开启
STRICT_TRANS_TABLES，它也只影响主 SQL，不传导进触发器上下文
自增 ID 仍会被消耗，造成 ID 断层且不可逆
哪怕触发器里的 INSERT IGNORE 最终什么都没插入，只要语句涉及自增列（如没显式指定 id），InnoDB 就已在执行早期预分配了一个 ID。这个 ID 不会回收，表的 AUTO_INCREMENT 值照常递增。
典型表现：高频触发场景下（如每笔订单都触发库存变更日志），日志表的主键 ID 疯狂跳跃，但实际行数增长缓慢，DBA 查 SHOW TABLE STATUS 会发现 Auto_increment 值远超真实数据量。
- 该行为与存储引擎无关，InnoDB 和 MyISAM 均如此
- 显式提供
id值（如INSERT IGNORE INTO log (id, ...) VALUES (@next_id, ...)）可绕过，但需额外维护 ID 生成逻辑 - 用 UUID 或雪花 ID 替代自增主键，才能彻底规避，但代价是索引变宽、范围查询变慢
锁行为未简化，反而增加死锁概率
INSERT IGNORE 在触发器中不会跳过加锁流程。它仍要申请插入意向锁（INSERT intention lock），再尝试对唯一键加 record lock 或 next-key lock。当多个事务并发触发相同逻辑（比如同时处理同一用户的多笔支付），极易因 gap 锁等待形成循环依赖。
常见错误现象：应用层看到 Deadlock found when trying to get lock，但日志里查不到 Duplicate entry 报错——说明冲突根本没走到“忽略”那步，而是卡死在锁排队阶段了。
- 二级唯一索引（非主键）比主键更易引发 next-key lock，锁范围更大
- 如果触发器还嵌套调用其他写操作，锁持有时间拉长，死锁窗口进一步扩大
- RR 隔离级别下，哪怕只是等值插入，InnoDB 仍可能对唯一索引的 gap 加锁
与其他 UPSERT 语法混用会导致语法错误或逻辑错乱
触发器里不能把 INSERT IGNORE 和 ON DUPLICATE KEY UPDATE 拼在一起，MySQL 直接报语法错误：ERROR 1064。更隐蔽的问题是：有人误以为 INSERT IGNORE 能“兜底”所有错误，结果字段超长、NULL 插 NOT NULL 列等非唯一性错误依然中断触发器执行，导致后续逻辑断链。
例如：触发器中写 INSERT IGNORE INTO audit (user_id, ip, created_at) VALUES (NEW.id, NEW.ip, NOW())，但 ip 字段是 VARCHAR(15)，而传入的是 IPv6 地址，此时 INSERT IGNORE 完全无效，整个触发器崩溃，事务回滚（如果在 BEFORE 触发器中）或中断（AFTER 中）。
-
INSERT IGNORE只抑制ER_DUP_ENTRY（错误码 1062），其他错误照常抛出 - 想真正兜住多种错误，得拆成多个
IF EXISTS (SELECT ...)+ 显式INSERT，但性能差、并发不安全 - 最务实的做法是：触发器只做轻量、确定性高的操作；复杂写入逻辑提到应用层，由业务控制幂等和重试
INSERT IGNORE 行为不受外层事务的 warning 处理策略影响，也不受客户端连接的 sql_mode 动态变更影响——它的警告降级逻辑是硬编码在执行器里的，一旦写进去，就只能靠事后查表或监控 AUTO_INCREMENT 增长速率来反推是否大量被忽略。 
