MySQL5.7 : Reduce lock_sys_t::mutex contention when converting implicit lock to an explicit lock

worklog: http://dev.mysql.com/worklog/task/?id=6899

Rev: http://bazaar.launchpad.net/~mysql/mysql-server/5.7/revision/5743

背景：
1.什么是隐式锁
所谓的隐式锁，可以理解成一个记录标记，在内存的锁对象hash中是不存在的。但我们在更新数据块时，会进行如下操作：
#对于聚集索引，每次更改或插入记录会同时写入对应的事务id和回滚段指针
#对于二级索引，每次更改/插入二级索引记录，会更新二级索引页的最大事务id。

我们知道，Innodb在插入记录时，是不加锁的。如果事务A插入记录rec1，且未提交时。事务b尝试update rec1，这时候事务b会去判断rec1上保存的事务id是否活跃，如果活跃的话，那么就 “帮助” 事务A 去建立一个锁对象，加入到hash中，然后自身进入等待事务A状态，也就是所谓的隐式锁转换为显式锁。

该worklog主要优化了该转换的过程


原始逻辑
参考函数lock_rec_convert_impl_to_expl

0.找到修改或插入当前记录的事务id （记做trx_id, 不持有锁）,如果不是活跃的事务id，不做操作，退出函数

1. Acquire the lock_sys_t::mutex
 2. (trx_rw_is_active)
 Acquire the trx_sys_t::mutex
 Scan the trx_sys_t::rw_trx_list for trx_id_t (only RW transactions can insert)
 Release the trx_sys_t::mutex
 Return handle if transaction found
 3. if handle found then
 do an implicit to explicit record conversion
 endif
 4. Release the lock_sys_t::mutex

可以看到，在该操作的过程中，全程持有lock_sys mutex，持有锁的原因是防止事务提交掉.当读写事务链表非常长时（例如高并发写入时），这种开销将是不可接受的。

优化后的逻辑

Acquire the trx_sys_t::mutex
 Scan the trx_sys_t::rw_trx_list for trx_id_t (only RW transactions can insert)
 if handle found then
 Acquire the trx_t::mutex
 Increment trx_t::n_ref_count ——增加计数，表示对这个事务进行隐式锁转换
 Release the trx_t::mutex
 endif
 Release the trx_sys_t::mutex
 Return handle if transaction found
 if handle found then
 Acquire the lock_sys_t::mutex
 do an implicit to explicit record conversion
 Release the lock_sys_t::mutex
 Acquire the trx_t::mutex
 Decrement trx_t::n_ref_count ——完成隐式转换，重置计数
 Release the trx_t::mutex
 endif

这里实际上在查找当前记录上的活跃事务id时，直接返回的是其事务对象，而不是事务id

在事务commit时进行检查 （函数lock_trx_release_locks）

Acquire the trx_t::mutex
 if trx_t::n_ref_count > 0
 while (trx_t::n_ref_count > 0) ———>当前正在做隐式到显式的锁转换
 Release the trx_t::mutex
 sleep/delay
 Acquire the trx_t::n_ref_count
 end while
 endif

通过该修改，我们可以在获取活跃事务对象的时候无需持有lock sys mutex。在低并发下，可能没有太多收益，但在高并发下，读写事务链表较长时，可能会影响到性能。

但该特性带来的额外开销是，事务在commit时需要检查ref count，理论上锁转换过程应该很快.