MySQL · 引擎特性 · InnoDB 事务锁简介

假设当前AUTO_INCREMENT值为101，在传统模式下执行完后，下一个自增值为103，而在新模式下，下一个可用的自增值为105，因为在开始执行SQL时，会先预取了[101, 104] 4个自增值，这和插入行的个数相匹配，然后将AUTO_INCREMENT设为105，导致自增值103和104被浪费掉。

AUTOINC_NO_LOCKING （2）

这种模式下只在分配时加个mutex即可，很快就释放，不会像NEW STYLE那样在某些场景下会退化到传统模式。因此设为2不能保证批量插入的复制安全性。

关于自增锁的小BUG

这是Mariadb的Jira上报的一个小bug，在row模式下，由于不走parse的逻辑，我们不知道行记录是通过什么批量导入还是普通INSERT产生的，因此command类型为SQLCOM_END，而在判断是否加自增锁时的逻辑时，是通过COMMAND类型是否为SQLCOM_INSERT或者SQLCOM_REPLACE来判断是否忽略加AUTO_INC锁。这个额外的锁开销，会导致在使用ROW模式时，InnoDB总是加AUTO_INC锁，加AUTO_INC锁又涉及到全局事务资源的开销，从而导致性能下降。

修复的方式也比较简单，将SQLCOM_END这个command类型也纳入考虑。

具体参阅 Jira链接

事务锁管理

InnoDB所有的事务所对象都是挂在全局对象lock_sys上，同时每个事务对象上也维持了其拥有的事务锁，每个表对象( dict_table_t )上维持了构建在其上的表级锁对象。

如下图所示：

加表级锁

• 首先从当前事务的 trx_lock_t::table_locks 中查找是否已经加了等同或更高级别的表锁，如果已经加锁了，则直接返回成功。（ lock_table_has ）
• 检查当前是否有和当前申请的锁模式冲突的表级锁对象（ lock_table_other_has_incompatible ）
  • 直接遍历链表 dict_table_t::locks 链表
• 如果存在冲突的锁对象，则需要进入等待队列（ lock_table_enqueue_waiting ）
  • 创建等待锁对象 （ lock_table_create ）
  • 检查是否存在死锁（ DeadlockChecker::check_and_resolve ），当存在死锁时：如果当前会话被选作牺牲者，就移除锁请求( lock_table_remove_low )，重置当前事务的wait_lock为空，并返回错误码DB_DEADLOCK；若被选成胜利者，则锁等待解除，可以认为当前会话已经获得了锁，返回成功。
  • 若没有发生死锁，设置事务对象的相关变量后，返回错误码DB_LOCK_WAIT，随后进入锁等待状态
• 如果不存在冲突的锁，则直接创建锁对象（ lock_table_create ），加入队列

lock_table_create : 创建锁对象

• 当前请求的是AUTO-INC锁时
  • 递增 dict_table_t::n_waiting_or_granted_auto_inc_locks 。前面我们已经提到过，当这个值非0时，对于自增列的插入操作就会退化到OLD-STYLE。
  • 锁对象直接引用已经预先创建好的 dict_table_t::autoinc_lock ，并加入到 trx_t::autoinc_locks 集合中。
• 对于非AUTO-INC锁，则从一个pool中分配锁对象。
  • 在事务对象 trx_t::lock 中，维持了两个pool，一个是 trx_lock_t::rec_pool ，预分配了一组锁对象用于记录锁分配，另外一个是 trx_lock_t::table_pool ，用于表级锁的锁对象分配。通过预分配内存的方式，可以避免在持有全局大锁时( lock_sys->mutex )进行昂贵的内存分配操作。rec_pool和table_pool预分配的大小都为8个锁对象。（ lock_trx_alloc_locks ）
  • 如果table_pool已经用满，则走内存分配，创建一个锁对象
• 构建好的锁对象分别加入到事务的 trx_t::lock.trx_locks 链表上以及表对象的 dict_table_t::locks 链表上。
• 构建好的锁对象加入到当前事务的 trx_t::lock.table_locks 集合中。

可以看到锁对象会加入到不同的集合或者链表中，通过挂载到事务对象上，可以快速检查当前事务是否已经持有表锁；通过挂到表对象的锁链表上，可以用于检查该表上的全局冲突情况。

加行级锁

行级锁加锁的入口函数为 lock_rec_lock ，其中第一个参数impl如果为TRUE，则当当前记录上已有的锁和 LOCK_X | LOCK_REC_NOT_GAP 不冲突时，就无需创建锁对象。（见上文关于记录锁LOCK_X相关描述部分），为了描述清晰，下文的流程描述，默认impl为false。

lock_rec_lock ：

• 首先尝试fast lock的方式，对于冲突少的场景，这是比较普通的加锁方式( lock_rec_lock_fast ), 符合如下情况时，可以走fast lock:
  • 记录所在的page上没有任何记录锁时，直接创建锁对象，加入rec_hash，并返回成功
  • 记录所在的page上只存在一个记录锁，并且属于当前事务，且这个记录锁预分配的bitmap能够描述当前的heap no （预分配的bit数为创建锁对象时的page上记录数 + 64，参阅函数 RecLock::lock_size ），则直接设置对应的bit位并返回。
• 无法走fast lock时，再调用slow lock的逻辑( lock_rec_lock_slow )
  • 判断当前事务是否已经持有了一个优先级更高的锁，如果是的话，直接返回成功（ lock_rec_has_expl ）
  • 检查是否存在和当前申请锁模式冲突的锁（ lock_rec_other_has_conflicting ），如果存在的话，就创建一个锁对象（ RecLock::RecLock ），并加入到等待队列中（ RecLock::add_to_waitq ），这里会进行死锁检测。
  • 如果没有冲突的锁，则入队列（ lock_rec_add_to_queue ）：已经有在同一个Page上的锁对象且没有别的会话等待相同的heap no时，可以直接设置对应的bitmap（ lock_rec_find_similar_on_page ）；否则需要创建一个新的锁对象。
• 返回错误码，对于DB_LOCK_WAIT, DB_DEADLOCK等错误码，会在上层进行处理。

等待及死锁判断

当发现有冲突的锁时，调用函数 RecLock::add_to_waitq 进行判断

• 如果持有冲突锁的线程是内部的后台线程（例如后台dict_state线程），这个线程不会被一个高优先级的事务取消掉，因为总是优先保证内部线程正常执行。
• 比较当前会话和持有锁的会话的事务优先级，调用函数trx_arbitrate 返回被选作牺牲者的事务
  • 当前发起请求的会话是后台线程，但持有锁的会话设置了高优先级时，选择当前线程作为牺牲者
  • 持有锁的线程为后台线程时，在第一步已经判断了，不会选作牺牲者
  • 如果两个会话都设置了优先级，低优先级的被选做牺牲者，优先级相同时，请求者被选做牺牲者( thd_tx_arbitrate )
  • PS: 目前最新版本的5.7还不支持用户端设置线程优先级（但增加一个配置session变量的接口非常容易)
• 如果当前会话的优先级较低，或者另外一个持有锁的会话为后台线程，这时候若当前会话设置了优先级，直接报错，并返回错误码DB_DEADLOCK。
  • 默认不设置优先级时，请求锁的会话也会被选作victim_trx，但只创建锁等待对象，不会直接返回错误。
• 当持有锁的会话被选作牺牲者时，说明当前会话肯定设置了高优先级，这时候会走 RecLock::enqueue_priority 的逻辑
  • 如果持有锁的会话在等待另外一个不同的锁时，或者持有锁的事务不是readonly的，当前会话会被回滚掉。
  • 开始跳队列，直到当前会话满足加锁条件（ RecLock::jump_queue ）
    • 请求的锁对象跳过阻塞它的锁对象，直接操作hash链表，将锁对象往前挪。
    • 从当前lock，向前遍历链表，逐个判断是否有别的会话持有了相同记录上的锁（ RecLock::is_on_row ），并将这些会话标记为回滚（ mark_trx_for_rollback ）,同时将这些事务对象搜集下来，以待后续处理。（但直接阻塞当前会话的事务会被立刻回滚掉）
  • 高优先级的会话非常具有杀伤力，其他低优先级会话即使拿到了锁，也会被它所干掉。

不过实际场景中，我们并没有多少机会去设置事务的优先级，这里先抛开这个话题，只考虑默认的场景，即所有的事务优先级都未设置。

在创建了一个处于WAIT状态的锁对象后，我们需要进行死锁检测（ RecLock::deadlock_check ），死锁检测采用深度优先遍历的方式，通过事务对象上的 trx_t::lock.wait_lock 构造事务的wait-for graph进行判断，当最终发现一个锁请求等待闭环时，可以判定发生了死锁。另外一种情况是，如果检测深度过长（即锁等待的会话形成的检测链路非常长），也会认为发生死锁，最大深度默认为 LOCK_MAX_DEPTH_IN_DEADLOCK_CHECK ，值为200。

当发生死锁时，需要选择一个牺牲者（ DeadlockChecker::select_victim() ）来解决死锁，通常事务权重低的回滚（ trx_weight_ge ）

• 修改了非事务表的会话具有更高的权重；
• 如果两个表都修改了、或者都没有修改事务表，那么就根据的事务的undo数量加上持有的事务锁个数来决定权值。（TRX_WEIGHT）
• 低权重的事务被回滚，高权重的获得锁对象。

Tips：对于一个经过精心设计的应用，我们可以从业务上避免死锁，而死锁检测本身是通过持有全局大锁来进行的，代价非常高昂，在阿里内部的应用中，由于有专业的团队来保证业务SQL的质量，我们可以选择性的禁止掉死锁检测来提升性能，尤其是在热点更新场景，带来的性能提升非常明显，极端高并发下，甚至能带来数倍的提升。

当无法立刻获得锁时，会将错误码传到上层进行处理（ row_mysql_handle_errors ）

• DB_LOCK_WAIT ：

  • 具有高优先级的事务已经搜集了会阻塞它的事务链表，这时候会统一将这些事务回滚掉（ trx_kill_blocking ）；
  • 将当前的线程挂起（ lock_wait_suspend_thread ），等待超时时间取决于session级别配置（ innodb_lock_wait_timeout ），默认为50秒。
  • 如果当前会话的状态设置为running，。一种是被选做死锁检测的牺牲者，需要回滚当前事务，另外一种是在进入等待前已经获得了事务锁，也无需等待
  • 获得等待队列的一个空闲slot。（ lock_wait_table_reserve_slot ）
    • 系统启动时，已经创建好了足够用的slot数组，类型为 srv_slot_t ，挂在 lock_sys->waiting_threads 上。
    • 分配slot时，从slot数组的第一个元素开始遍历，直到找到一个空闲的slot。注意这里存在的一个性能问题是，如果挂起的线程非常多，每个新加入挂起等待的线程都需要遍历直到找到一个空闲的slot。 实际上如果每次遍历都从上次分配的位置往后找，到达数组末尾在循环到数组头，这样可以在高并发高锁冲突场景下获得一定的性能提升。
  • 如果会话在innodb层（通常为true），则强制从InnoDB层退出，确保其不占用 innodb_thread_concurrency 的槽位。然后进入等待状态。被唤醒后，会再次强制进入InnoDB层
  • 被唤醒后，释放slot（ lock_wait_table_release_slot ）
  • 若被选作死锁的牺牲者了，返回上层回滚事务；若等待超时了，则根据参数 innodb_rollback_on_timeout 的配置，默认为OFF只回滚当前SQL，设置为ON表示回滚整个事务。

• DB_DEADLOCK : 直接回滚当前事务

释放锁及唤醒

大多数情况下事务锁都是在事务提交时释放，但有两种意外：

• AUTO-INC锁在SQL结束时直接释放（ innobase_commit --> lock_unlock_table_autoinc ）
• 在RC隔离级别下执行DML语句时，从引擎层返回到Server层的记录，如果不满足where条件，则需要立刻unlock掉。（ ha_innobase::unlock_row ）

除这两种情况外，其他的事务锁都是在事务提交时释放的。( lock_trx_release_locks --> lock_release )。 事务持有的所有锁都维护在链表 trx_t::lock.trx_locks 上，依次遍历释放即可。

对于行锁，从全局hash中删除后，还需要判断别的正在等待的会话是否可以被唤醒（ lock_rec_dequeue_from_page ）。例如如果当前释放的是某个记录的X锁，那么所有的S锁请求的会话都可以被唤醒。

这里的移除锁和检查的逻辑开销比较大，尤其是大量线程在等待少量几个锁时。当某个锁从hash链上移除时，InnoDB实际上通过遍历相同page上的所有等待的锁，并判断这些锁等待是否可以被唤醒。而判断唤醒的逻辑又一次遍历，这是因为当前的链表维护是基于的，并不是基于Heap no构建的。关于这个问题的讨论，可以参阅 bug#53825 。官方开发Sunny也提到虽然使用来构建链表，移除Bitmap会浪费更多的内存，但效率更高，而且现在的内存也没有以前那么昂贵。

对于表锁，如果表级锁的类型不为LOCK_IS，且当前事务修改了数据，就将表对象的 dict_table_t::query_cache_inv_id 设置为当前最大的事务id。 在检查是否可以使用该表的Query Cache时会使用该值进行判断（ row_search_check_if_query_cache_permitted ），如果某个用户会话的事务对象的low_limit_id（即最大可见事务id）比这个值还小，说明它不应该使用当前table cache的内容，也不应该存储到query cache中。

表级锁对象的释放调用函数 lock_table_dequeue

注意在释放锁时，如果该事务持有的锁对象太多，每释放1000（ LOCK_RELEASE_INTERVAL ）个锁对象，会暂时释放下 lock_sys->mutex 再重新持有，防止InnoDB hang住。

两个有趣的案例

本小节我们来分析几个比较有趣的死锁案例。

普通的并发插入导致的死锁

create table t1 (a int primary key);开启三个会话执行： insert into t1(a) values (2);

上述描述了互相等待的场景，因为插入意向X锁和S锁是不相容的。这也是一种典型的锁升级导致的死锁。 如果session1执行COMMIT的话，则另外两个线程都会因为duplicate key失败。

这里需要解释下为何要申请插入意向锁，因为ROLLBACK时原纪录回滚时是被标记删除的。而我们尝试插入的纪和这个标记删除的纪录是相邻的(键值相同)，根据插入意向锁的规则，插入位置的下一条纪录上如果存在与插入意向X锁冲突的锁时，则需要获取插入意向X锁。

另外一种类似（但产生死锁的原因不同）的场景是在一张同时存在聚集索引和唯一索引的表上，通过replace into的方式插入冲突的唯一键，可能会产生死锁，在3月份的月报，我已经专门描述过这个问题，感兴趣的可以 延伸阅读下

又一个并发插入的死锁现象

引起这个死锁的原因是非插入意向的GAP X锁和插入意向X锁之间是冲突的。