数据库活锁真烦人，教你几招别让它一直转圈圈

（引用来源：综合自数据库管理员社区讨论、知乎专栏“数据库内核漫谈”以及《高性能MySQL》中的相关概念解释）

数据库活锁真烦人,教你几招别让它一直转圈圈

你有没有遇到过这种情况：明明感觉数据库服务器也没死机，CPU吭哧吭哧转得挺欢，但你的那个关键业务操作，比如下单、支付，就是卡在那里，像个转圈圈加载的网页，半天没反应？等啊等，最后可能要么超时失败了，要么又莫名其妙好了，这种时候，你心里可能已经骂了一万遍“这破数据库又卡了！”。

这种“没死但卡住”的烦人情况，很多时候不是“死锁”，而是它的一个讨厌的“亲戚”——活锁，死锁是大家抱在一起死，谁都动不了，数据库一般能检测到并把其中一个“干掉”来解决问题，而活锁更气人，大家都没死，都在努力地“谦让”或者“抢跑”，但就是有个别倒霉蛋一直轮不到机会，像个在旋转门里总被人挤出去的可怜虫，一直在尝试，一直失败，看起来就像“活”着，但工作毫无进展。

那这个“谦让”和“抢跑”是怎么发生的呢？举个不太严谨但很好懂的例子，想象一下高峰期只有一个闸机的地铁站，规定一次只能过一个人。

谦让出的麻烦（常见于简单的锁机制） 你和小张同时冲到闸机口，数据库系统（好比保安）看到你俩同时来了，觉得这样不行，得有个先来后到，它可能根据一个非常细微的时间差，比如你的请求比小张早了0.0001秒，于是保安对小张说：“你，退后一步，让他先过。”小张很听话，退后了一步，就在你正准备刷卡的时候，旁边又冲过来一个老王，保安一看，又来一个，于是同样比较时间戳，可能发现老王比你“当前”这个状态更“新”一点，又对你说：“你，也退后一步，让老王先过。”你只好退后，你刚退后，小张又尝试上前，保安又可能让你前面的人退后……结果就是你和小张这两个先来的，不断地被要求“谦让”给后来者，虽然你们都在活动（尝试过闸机），但就是永远轮不到，这就是一种活锁。

抢跑惹的祸（常见于队列处理） 再换一种情况，现在闸机前面排起了队，你是第一个，闸机每次放行一个人后，会有一个极短的重新开放时间，每次你刚要迈腿，后面有个身手特别敏捷的人（比如一个被设置了高优先级的查询），“嗖”一下就插队抢在你前面通过了，你每次都想下一个该我了吧，但每次都被插队，虽然队伍在动，但你永远在队首原地踏步，这也是活锁。

那么在真实的数据库里,是什么导致了这些“谦让”和“抢跑”呢？

1. 事务设计不当：如果你的事务特别长，占着茅坑不拉屎，锁定了很多数据，其他短平快的事务每次来都想访问这些数据，但发现被锁着，可能根据数据库的策略，短事务会短暂等待后放弃重试，如果长事务一直不结束，就可能出现无数短事务不断重试又失败的现象，对它们来说就遇到了活锁。
2. 锁的粒度不合适：比如系统默认使用了比较粗的表锁，一个人只是在修改表里的一行数据，却锁住了整张表，其他人哪怕想修改完全不相关的另一行，也得等着，如果修改操作很频繁，就会造成大量事务在队列里等待，虽然锁持有者很快会释放，但等待队列可能很长，队尾的事务可能等得花儿都谢了。
3. 不合理的重试机制：应用程序发现操作失败（比如因为锁超时）后，如果立即、无延迟地重试，而且重试间隔非常短，那么它很可能下一次又撞在同一个锁上，如果多个程序都这样“无脑重试”，就会加剧资源争抢，增加某些请求永远被“挤开”的概率。
4. 数据库内部的资源调度：有些数据库系统在处理并发读写时，为了保障数据一致性，可能会有一些内部的调度策略，比如在MVCC（多版本并发控制，你可以理解为给数据拍快照）的机制下，如果读写冲突非常频繁，某些查询可能为了找到一个合适的“快照版本”而不断尝试，也可能陷入类似活锁的状态。

那怎么解决这个烦人的“转圈圈”问题呢？教你几招实用的，别让它一直耗着你：

第一招：让事务“短小精悍” 这是最根本的一招，就像在超市排队，你如果只买一瓶水，肯定比推着满满一车货的人结账快，数据库事务也是同理，尽量把事务设计得短一些，快进快出，在开启事务之前，就把所有需要准备的工作做完（比如数据校验、计算），进入事务后，只做最核心的增删改查操作，然后立刻提交，千万不要在事务里执行网络请求、调用外部接口、或者让人工手动确认这种耗时操作，这相当于你结账时突然想起来还要再拿个东西，让后面所有人干等着。

第二招：给等待加点“随机性” 如果你的程序因为锁冲突失败需要重试，千万别傻乎乎地立刻、用同样的间隔去重试，这相当于在闸机口被推回来后，立刻又以同样的速度冲上去，很可能又会被同一批人推回来，正确的做法是采用“指数退避”策略，比如第一次失败等1秒，第二次失败等2秒，第三次等4秒……这样给系统一个喘息的机会，让可能持有锁的事务完成操作，或者，即使在固定间隔重试，也可以在间隔时间上加一个随机数，打散多个程序同时重试的节奏，避免它们再次“撞车”。

第三招：排好队，别抢 审视一下你的业务逻辑，是不是有些操作本质上就需要严格的顺序？比如给同一个订单顺序生成流水号，对于这种场景，可以考虑在应用层引入一个队列机制，让请求排队处理，或者使用数据库提供的序列号生成器，从根源上避免抢锁。

第四招：找DBA帮你“调调参数” 如果问题出在数据库层面，可能就需要数据库管理员出手了，他们可以：

• 调整锁超时时间：设置一个合理的锁等待超时时间，太短会导致不必要的失败，太长则可能让活锁现象持续更久，找到一个平衡点。
• 审视隔离级别：降低事务的隔离级别（比如从“可重复读”降到“读已提交”）可以减少锁的竞争，但这需要评估对数据一致性的影响。
• 优化索引和SQL：一个慢查询会持有锁更长时间，通过优化索引，让SQL执行得更快，也能加速锁的释放。

第五招：换个思路，避免锁 这是更高阶的玩法，比如使用乐观锁，不对数据直接加锁，而是在更新时检查一下数据版本号是否变化，如果变了就说明有人改过，那就重新读取数据再尝试更新，这就像大家都可以同时编辑文档，但保存时会检查有没有冲突，这种方式在高并发读、低并发写的场景下特别有效。

活锁虽然烦人,但它通常不是数据库的“绝症”，它更像一个信号，提醒你系统的并发设计可能存在问题，通过分析业务场景，优化事务和代码，再配合一些简单的重试策略，你完全有能力把这个不停“转圈圈”的家伙给摆平，让你的数据库操作重新变得流畅起来。