INSERT IGNORE在高并发下会静默吞掉关键错误，如字段截断、NOT NULL违反、时区转换失败等，导致数据失真且影响行数不可靠；应改用INSERT ... ON DUPLICATE KEY UPDATE，并确保冲突字段有唯一索引、事务顺序一致、正确使用VALUES()。
为什么INSERT IGNORE在高并发下会静默吞掉关键错误
INSERT IGNORE看起来省事，但它不区分错误类型：除了ERROR 1062 (23000): Duplicate entry，还会忽略字段截断、NOT NULL约束违反、时区转换失败等本该报警的问题。业务日志里看不到异常，但数据可能已失真。
更麻烦的是，它返回的影响行数不可靠——冲突时返回 0，成功插入才返回 1，无法据此判断“是真插入了还是被跳过了”。批量写入时，你根本不知道哪几条丢了。
- 别用
INSERT IGNORE做幂等写入，除非你能接受所有警告级错误都被丢弃 - 如果必须用，至少加
SHOW WARNINGS检查，但线上高频场景不现实 - 真正需要的是明确语义：
INSERT ... ON DUPLICATE KEY UPDATE能返回准确影响行数（1=新插入，2=更新）
ON DUPLICATE KEY UPDATE失效的典型原因
这个语句不是万能的。它只在冲突字段上有**唯一索引（主键或UNIQUE KEY）**时才生效。如果WHERE条件或ON DUPLICATE KEY引用的列没建唯一索引，MySQL 直接报语法错误或退化为全表扫描+锁竞争。
常见踩坑点：
- 误以为
INDEX就够了——普通索引不触发ON DUPLICATE KEY UPDATE，必须是UNIQUE或PRIMARY KEY - 联合唯一索引顺序写反：比如索引是
(a, b)，但冲突判断只依赖b，InnoDB 无法定位，照样扫表 - 字段类型隐式转换导致索引失效：如
varchar字段存数字但查询用int，索引失效 → 查找变慢 → 间隙锁范围扩大 → 并发阻塞加剧
死锁不是语法问题，是索引和事务顺序问题
两个并发事务同时执行INSERT ... ON DUPLICATE KEY UPDATE，哪怕都命中同一唯一键，也可能死锁。根本原因不是语句本身，而是：
- 没有唯一索引时，InnoDB 在查找过程中会对“可能插入的位置”加间隙锁，多个事务锁同一间隙就互等
- 事务中操作多张表，但顺序不一致：比如事务 A 先改
users再改user_settings，事务 B 反过来，形成环形等待 -
SELECT ... FOR UPDATE没走唯一索引：比如WHERE user_id = ?但user_id没索引，就会锁整张表或大量无关行
解决方法很实在：先确保冲突字段有唯一索引，再统一所有 DAO 层对关联表的访问顺序（例如永远先accounts后orders），而不是指望重试或调参数。
批量写入时VALUES()容易写错
ON DUPLICATE KEY UPDATE里的VALUES(col)指的是本次INSERT子句中该列的值，不是原记录值。新手常误写成col = col + 1，结果变成“原值加 1”，而不是“新值加 1”。
示例对比：
INSERT INTO counters (id, count) VALUES (123, 1) ON DUPLICATE KEY UPDATE count = count + 1; -- ❌ 错：读原值再加，两次并发都读到 1 → 都写 2
INSERT INTO counters (id, count) VALUES (123, 1) ON DUPLICATE KEY UPDATE count = VALUES(count) + 1; -- ✅ 对：用本次传入的 1 加 1 → 写 2；下次再插 1 就写 3
注意：VALUES()只能用于INSERT子句中明确列出的字段，不能用于子查询或函数表达式，否则报错。
真正卡住你的，往往不是语法不会写，而是唯一索引没建对、事务顺序没控住、或者VALUES()语义没吃透——这些地方一错，高并发下不是报错，而是慢、堵、死锁，还难复现。
