死锁主因是事务执行过长而非并发高；应缩短事务、移除非db操作、确保sql走索引、用批量语句替代循环、合理设隔离级别为read committed。
死锁不是锁太多，是事务等太久
MySQL死锁高频发生，根本原因往往不是并发量大，而是单个事务执行时间过长、持有锁的时间超出必要范围。InnoDB 的行级锁本身很精细，但一旦事务里混入慢查询、网络延迟、应用层循环处理或没加索引的 WHERE 条件，就会让锁“卡”住，其他事务一凑上来就容易撞死锁。
实操上优先砍掉事务里的非数据库操作：比如发邮件、调外部 HTTP 接口、格式化大量数据——这些必须挪到 COMMIT 之后。事务只做纯粹的读写，越短越好。
- 用
SHOW ENGINE INNODB STATUS\G查最近死锁详情，重点关注TRANSACTION块里的lock_wait_time和 SQL 语句 - 所有
UPDATE/DELETE必须走索引，否则会升级为表锁或锁全扫描范围，极易引发冲突 - 避免在事务中
SLEEP()或人为WAIT FOR，这类写法在压测时几乎必现死锁
批量更新别用单条循环，改用 INSERT ... ON DUPLICATE KEY UPDATE
常见错误是用应用层 for 循环执行几十次 UPDATE，每条都开启独立锁等待。这不仅放大锁持有时间，还让事务日志暴涨、主从延迟加剧。
真正高效的做法是把多条变更聚合成一条语句。例如要更新用户积分，别写 100 次 UPDATE user SET score = score + ? WHERE id = ?，改用：
INSERT INTO user (id, score) VALUES (1, 10), (2, 20), (3, 15) ON DUPLICATE KEY UPDATE score = score + VALUES(score);
这样整个操作在一次事务内完成，锁只在必要行上短暂存在，且避免了重复解析和网络往返。
- 注意
VALUES()是 MySQL 特有语法，不能写成score = score + ? - 表必须有
PRIMARY KEY或UNIQUE KEY，否则ON DUPLICATE KEY UPDATE不生效 - 如果批量数据超 1000 行，建议分批（如 500 行/批），避免单条 SQL 过大触发
max_allowed_packet限制
SELECT ... FOR UPDATE 要带 WHERE 且命中索引，否则锁表风险极高
SELECT ... FOR UPDATE 看似只是查，实际会加写锁。如果没走索引，InnoDB 可能对整个扫描范围加锁——哪怕你只想要一行，也可能锁住几千行甚至整张表，其他事务一碰就死锁。
验证是否走索引很简单：在语句前加 EXPLAIN，看 type 是不是 const/ref，key 列有没有显示索引名。
- 禁止在没有
WHERE条件下用SELECT ... FOR UPDATE，哪怕只是测试 - 复合索引要注意最左匹配，
WHERE status = 1 AND user_id = 123如果索引是(user_id, status)，就无法命中 - 如果业务允许，考虑用
SELECT ... LOCK IN SHARE MODE替代，它兼容性更好，冲突概率更低
事务隔离级别别盲目设 SERIALIZABLE，READ COMMITTED 更适合高并发更新场景
很多人以为 “越高级越安全”，把全局隔离级别设成 SERIALIZABLE，结果发现死锁率翻倍。这是因为 SERIALIZABLE 会让普通 SELECT 也加间隙锁（gap lock），大幅扩大锁范围。
对绝大多数 Web 应用，READ COMMITTED 是更务实的选择：它关闭间隙锁（除唯一索引的等值查询外），减少锁冲突；同时能防止脏读，满足一致性底线。
- 用
SELECT @@tx_isolation查当前会话级别，用SELECT @@global.tx_isolation查全局设置 - 修改全局级别：执行
SET GLOBAL tx_isolation = 'READ-COMMITTED'，需 SUPER 权限 - 注意：MySQL 8.0+ 默认已是
READ-COMMITTED，老版本（如 5.6/5.7）默认是REPEATABLE-READ，升级后务必确认
真正难的不是选哪个方案，而是意识到：死锁日志里那几行 SQL，背后大概率藏着一个没被监控到的慢查询、一个漏建的索引、或者一段在事务里悄悄 sleep 的调试代码。盯住 INNODB STATUS 里的锁等待时间，比调参数有用得多。
