行锁功过：怎么减少行锁对性能的影响？

什么是两阶段锁

两阶段锁协议（Two-Phase Locking Protocol）是一种并发控制机制，旨在保证事务的隔离性和原子性。这样可以避免死锁的发生，提高数据库的性能和并发度。

该协议分为两个阶段：

1. 增长阶段（Growing Phase）：事务在执行过程中，需要获取需要的所有锁。在这个阶段中，事务可以获取锁，但是不能释放锁。
2. 缩减阶段（Shrinking Phase）：当事务执行完毕后，需要释放所有锁。在这个阶段中，事务可以释放锁，但是不能获取锁。

即行锁在事务结束时才释放。比如对于下面的事务 A 和事务 B：

只有在事务 A 执行 commit 之后，事务 B 才能继续执行。

怎么利用好两阶段锁

假设你负责实现一个电影票在线交易业务，顾客 A 要在影院 B 购买电影票。我们简化一点，这个业务需要涉及到以下操作：

1. 从顾客 A 账户余额中扣除电影票价；
2. 给影院 B 的账户余额增加这张电影票价；
3. 记录一条交易日志。

也就是说，要完成这个交易，我们需要 update 两条记录，并 insert 一条记录。当然，为了保证交易的原子性，我们要把这三个操作放在一个事务中。那么，那么该如何安排这三个语句在事务中的顺序呢？

假设另外一个顾客 C 也在影院 B 买票，那么事务冲突的部分就是语句 2。因为它们要更新同一个影院账户的余额，需要修改同一行数据。

这样如果我们把容易冲突的语句 2 放在最后，这就能最大程度地减少了事务之间的锁等待，提升了并发度。

但是有一天影院做活动，可以低价预售一年内所有的电影票，而且这个活动只做一天。于是在活动时间开始的时候，你的 MySQL 就挂了。你登上服务器一看，CPU 消耗接近 100%，但整个数据库每秒就执行不到 100 个事务。这是什么原因呢？

这里，就要说到死锁和死锁检测了。

死锁和死锁检测

当并发系统中不同线程出现循环资源依赖，涉及的线程都在等待别的线程释放资源时，就会导致这几个线程都进入无限等待的状态，称为死锁。比如：

这时候，事务 A 在等待事务 B 释放 id=2 的行锁，而事务 B 在等待事务 A 释放 id=1 的行锁。 事务 A 和事务 B 在互相等待对方的资源释放，就是进入了死锁状态。

如何处理死锁状态

1. 直接进入等待，直到超时。这个超时时间可以通过参数 innodb_lock_wait_timeout 来设置。
2. 发起死锁检测，发现死锁后，主动回滚死锁链条中的某一个事务，让其他事务得以继续执行。将参数 innodb_deadlock_detect 设置为 on，表示开启这个逻辑。

一般我们会选择策略 2

因为在第一种策略下，如果设置的时间过长，那么意味着其他事务也要等待较长的时间，对于一个在线服务来说这是难以接受的。而如果设置时常过短，则容易出现等待超时正常的锁等待。

策略 2：主动死锁检测，而且 innodb_deadlock_detect 的默认值本身就是 on。

主动死锁检测在发生死锁的时候，是能够快速发现并进行处理的，但是它也是有额外负担的。因为不管是否发生死锁，当一个事务被锁住就要进行死锁监测。

而当出现上述影院做活动时，由于流量太多，就算我们把冲突的语句放在最后依然会存在大量事务等待的情况，而在这种情况下死锁监测这个操作的时间复杂度高达 O(n^2)，即假设有 1000 个并发线程要同时更新同一行，那么死锁检测操作就是 100 万这个量级的。因此会出现 CPU 直接干到 100% 的情况，事务却没有执行几个的情况。

如何热点行更新导致的性能问题

对于上述影院做活动出现的情况，我们称其为热点行更新导致的性能问题，那么对于这种问题有哪些解决方案呢？

1. 如果你能确保这个业务一定不会出现死锁，可以临时把死锁检测关掉。
2. 控制并发度，但建议从服务端限制，因为如果从客户端限制，由于一个服务端可能有多个客户端，就算限制客户端的并发线程最多 5 个，但如果客户端有上百个，还是容易出现高并发的情况。
3. 将冲突行的逻辑改成多个语句。比如上述的更新影院账户，可以把账户余额分配到十个记录中，但进行执行更新影院账户的操作时随机选择一个记录进行更新，而影院账户的总余额就是十条记录相加的结果。