前几天有个做电商的朋友半夜打电话过来，说数据库突然卡死，订单表写不进去，用户在前台下单全失败，客服电话被打爆了。我远程连上去一看，MySQL的监控面板上写着“Deadlock found when trying to get lock”。这种问题出现的频率其实比很多人想象的高，尤其是在高并发写入的场景下。死锁不是MySQL在跟你开玩笑，它是数据库的一种自我保护机制——两个事务互相等待对方释放资源，谁也不肯放手，MySQL只好挑一个杀掉。
很多人听到“死锁”两个字就紧张，觉得是什么高深莫测的东西。其实死锁的本质并不复杂，就是两个或多个事务在争夺同一批资源的时候，形成了环状等待。举个例子，事务A先锁住了行1，又想锁行2；事务B先锁住了行2，又想锁行1。这两个事务谁都不肯让步，MySQL的锁管理器检测到这种循环等待，就直接报错。但问题在于，很多死锁并不是因为并发量真的高到离谱，而是因为SQL写得不够“规矩”。
最常见的死锁场景之一是“批量更新没有统一排序”。比如一个订单系统，用户下单后要同时扣库存、更新订单状态、记录日志。三个更新操作分布在不同的表或不同的行上。如果事务A先扣库存再更新订单，事务B先更新订单再扣库存，那么当两个事务并发执行时，就很容易形成交叉等待。更麻烦的是，这种死锁不是每次都会触发，它跟并发时机密切相关。所以很多开发者在测试环境跑得好好的，一上线就崩，因为测试环境没有真正的并发压力。
解决这类死锁最直接的办法就是给所有更新操作统一排序。不管是先更新哪张表，所有事务都按照固定的顺序去执行。比如规定“先更新订单表，再更新库存表，最后更新日志表”。这样一来，事务A和事务B都在抢同一批锁，而不是相互抢对方的锁，循环等待自然就消失了。这个方法看起来简单，但很多团队在写业务代码时压根没考虑过锁顺序的问题，每个人按自己习惯写SQL，死锁就埋下了。
还有一类死锁是由“间隙锁”引发的。在MySQL的InnoDB引擎里，当使用可重复读隔离级别时，为了防止幻读，不仅会锁住已有的行，还会在行之间加上间隙锁。这就意味着，即使你只是更新了一行数据，也可能锁住它前后一段范围。如果两个事务同时往同一个间隙里插入数据，或者同时更新间隙里的行，死锁的概率直线上升。我见过一个典型的案例：一个抽奖活动表，用户每次抽奖都会插入一条记录。因为表里用了自增ID作为主键，但业务上根据用户ID做了范围查询，两个用户同时抽奖时，间隙锁互相卡住，死锁频繁出现。
解决办法很简单：要么把隔离级别降到读已提交，要么在业务表上加上合适的索引，让范围查询变成等值查询。读已提交级别不会产生间隙锁，死锁概率大幅降低。但降隔离级别之前要评估业务场景是否允许幻读。如果业务对数据一致性要求极高，比如金融交易，那就只能通过索引优化来缩小锁范围。把查询条件里用到的字段做成联合索引，让MySQL能精确找到要锁的行，而不是锁一大片。
索引设计不合理也是死锁的温床。比如一张订单表，查询条件用了用户ID和订单状态两个字段，但索引只有用户ID。MySQL在执行更新时，先用用户ID索引找到一批行，然后逐行加锁。如果另一个事务也拿着不同的用户ID进来，扫描范围可能出现交叉，导致死锁。更麻烦的是，当索引的选择性很差时，MySQL可能会选择全表扫描，一锁就是整个表，并发写入直接串行化。这时候死锁倒是不常见了，但性能也完蛋了。
合理做法是：为更新操作涉及的查询条件建立合适的联合索引，把选择性高的字段放在前面，让MySQL能用上索引而不是走全表。同时，避免在WHERE条件里用函数或者隐式类型转换，否则索引失效，锁范围瞬间扩大。索引优化这件事，很多开发者在建表时觉得“先跑起来再说”，结果等业务量上来，死锁和慢查询一起找上门。
如果死锁已经频繁到影响线上业务，短期内没法改代码和索引，那就要靠应用层的重试机制来兜底。MySQL的死锁报错是一个返回码，业务代码里捕获到这个异常后，自动重试事务。重试次数一般设3到5次，每次重试之间加一点随机延迟，避免所有客户端同时重试撞车。这个方案虽然治标不治本，但在紧急情况下能保住业务不中断。很多大厂在核心交易链路里都会加一重重试逻辑，不是因为他们写的代码不会死锁，而是他们知道死锁不可能完全杜绝。
还有一个容易被忽视的点：事务的粒度。有些开发者在写业务逻辑时，喜欢在一个事务里塞一大堆操作，比如先查用户信息，再查商品详情，然后更新订单，再发消息通知，记录日志。一个事务执行时间长达几百毫秒甚至几秒，持有锁的时间越长，其他事务等待的时间就越长，死锁的概率就越大。合理做法是：把非必要的操作移出事务，只让真正需要原子性的操作留在事务里。查用户信息、查商品详情这些读操作，完全可以放在事务外面。
监控和报警也是死锁治理的重要环节。MySQL本身提供了SHOW ENGINE INNODB STATUS这个命令，可以查看最近一次死锁的详细信息，包括哪些事务参与了死锁、它们执行了什么SQL、持有和等待哪些锁。把这个信息抓出来分析，就能精准定位是哪个业务场景触发了死锁。很多公司的做法是写一个定时任务，每隔几分钟抓一次死锁日志，解析后推送到告警系统。这样死锁一出现，开发人员马上就能看到现场，而不是等用户投诉了才去翻日志。
想说，死锁不是MySQL的bug，是并发编程的固有难题。你不可能写出一套代码永远不发生死锁，但可以通过规范写法、合理索引、合适隔离级别、事务粒度控制、重试机制和监控报警，把死锁的影响降到最低。回到开头那个电商朋友的案例，我帮他改了三件事：所有更新操作统一排序、把隔离级别降到读已提交、加了一个三秒超时和三次重试。从那以后，他的订单系统再没因为死锁出过问题。有时候解决问题的关键，不是堆更多机器，而是把代码写得更“懂”数据库的锁是怎么工作的。
