隐式锁
Lock 是一种悲观的顺序化机制。它假设很可能发生冲突，因此在操作数据时，就加锁。
如果冲突的可能性很小，多数的锁都是不必要的。
Innodb 实现了一个延迟加锁的机制，来减少加锁的数量，在代码中称为隐式锁(Implicit Lock)。
隐式锁中有个重要的元素,事务ID（trx_id).隐式锁的逻辑过程如下：
A. InnoDB的每条记录中都一个隐含的trx_id字段，这个字段存在于簇索引的B+Tree中。
B. 在操作一条记录前，首先根据记录中的trx_id检查该事务是否是活动的事务(未提交或回滚).
如果是活动的事务，首先将隐式锁转换为显式锁(就是为该事务添加一个锁)。
C. 检查是否有锁冲突，如果有冲突，创建锁，并设置为waiting状态。如果没有冲突不加锁,跳到E。
D. 等待加锁成功，被唤醒，或者超时。
E. 写数据，并将自己的trx_id写入trx_id字段。Page Lock可以保证操作的正确性。
相关代码：
A. lock_rec_convert_impl_to_expl()将隐式锁转换成显示锁。
B. 加锁和测试行锁冲突都用lock_rec_lock(),它的第一个参数表示是否是隐式锁。所以要特别
注意这个参数。如果为TRUE，在没有冲突时并不会加锁。
C. 测试行锁的冲突的具体内容在lock_rec_has_wait()
D. 创建waiting锁是lock_rec_enqueue_waiting()
E. 创建行锁是lock_rec_add_to_queue()
– 隐式锁的特点
A. 只有在很可能发生冲突时才加锁，减少了锁的数量。
B. 隐式锁是针对被修改的B+Tree记录，因此都是Record类型的锁。不可能是Gap或Next-Key类型。
– 隐式锁的使用
A. INSERT操作只加隐式锁，不需要显示加锁。
B. UPDATE,DELETE在查询时，直接对查询用的Index和主键使用显示锁，其他索引上使用隐式锁。
理论上说，可以对主键使用隐式锁的。提前使用显示锁应该是为了减少死锁的可能性。
INSERT，UPDATE，DELETE对B+Tree们的操作都是从主键的B+Tree开始，因此对主键加锁可以
有效的阻止死锁。
– Secondary Index上的隐式锁
前边说了, trx_id只存在于主键上，那么辅助索引上如何来实现隐式索引呢？
显然是要通过辅助索引中的主键值，在主键B+Tree上进行二次查找。这个开销是很大的。
InnoDB对这个过程有一个优化：
A. 每个页上有一个MAX_TRX_ID,每次修改辅助索引的记录时，都会更新这个最大事务ID。
B. 当判断是否要将隐式锁变为显式锁时，先将页面的max_trx_id和事务列表的最小trx_id
比较。如果max_trx_id比事务列表的最小trx_id还小，那么就不需要转换为显示锁了。
###################END#########################
|–> sel_set_rec_lock 加记录锁函数
|–>如果是聚集索引:lock_clust_rec_read_check_and_lock
|–>如果是二级索引:lock_sec_rec_read_check_and_lock
|–>lock_rec_convert_impl_to_expl 只有这个文件page记录的最大事务ID>=当前事务列表上的最小事务ID时，或者当前正在进行recovery时，一些事务可能在记录上有一个隐式x锁
>>如果是聚集索引：impl_trx = lock_clust_rec_some_has_impl
>>如果是二级索引：impl_trx = lock_sec_rec_some_has_impl_off_kernel
>>当前二级索引页上的MAX_TRX_ID小于当先事务列表上最小事务ID，
>>检查事务id是否有效lock_check_trx_id_sanity，页面可能被损坏
|–>row_vers_impl_x_locked_off_kernel 检查是否有事务插入或修改了二级索引记录，如果有，则返回该trx
>>如果impl_trx没有持有显式锁，则将其转换为显式锁(lock_rec_has_expl) ,
并加入到队列中(lock_rec_add_to_queue)
|–>lock_rec_queue_validate
函数row_vers_impl_x_locked_off_kernel用于检查是否有事务插入或修改了二级索引记录，
clust_rec = row_get_clust_rec(BTR_SEARCH_LEAF, rec, index,
这是个耗时操作，因此会释放kernel mutex；当然释放锁也要遵守latch order约定。在cluster index 记录上的latch锁住了版本栈的顶部，也会保留purge_latch来锁住版本栈的底部。
Fetches the clustered index record for a secondary index record. The latches
on the secondary index record are preserved.
@return record or NULL, if no record found */
当clust_rec为NULL时，返回NULL，这种情况比较少见。
根据注释的解释，在函数row_undo_mod_remove_clust_low()中我们已经移除了clust rec，而这时候purge还在清理和移除由之前版本的聚集索引记录分配的二级索引记录。这种情况下在二级索引记录上没有任何隐式锁，因为一个已经修改了二级索引记录的活跃事务同样也修改了聚集索引记录。在回滚时也是在聚集索引之前undo二级索引。
mtr_s_lock(&(purge_sys->latch), &mtr);
3)判断clust rec中的trx_id是否还是活跃id,如果不是活跃的，则表明没有隐式锁
/* We look up if some earlier version, which was modified by the trx_id
transaction, of the clustered index record would require rec to be in
a different state (delete marked or unmarked, or have different field
values, or not existing). If there is such a version, then rec was
modified by the trx_id transaction, and it has an implicit x-lock on
rec. Note that if clust_rec itself would require rec to be in a
different state, then the trx_id transaction has not yet had time to
modify rec, and does not necessarily have an implicit x-lock on rec. */
trx_undo_prev_version_build() 获取前一个版本的聚集索引记录
if (prev_version == NULL) {
如果事务是活跃事务，表面是刚插入的记录，含有隐式x-lock，获得根据trx_id获得trx
vers_del = rec_get_deleted_flag(prev_version, comp);
prev_trx_id = row_get_rec_trx_id(prev_version, clust_index,
if (vers_del && trx_id != prev_trx_id) {
mutex_enter(&kernel_mutex);
###这里存在bug#65389，这段判断是没有必要的，应该删除
因为被删除的二级索引记录项可能会被随后的insert重用，导致这里的判断为true。
row = row_build(ROW_COPY_POINTERS, clust_index, prev_version,
clust_offsets, NULL, &ext, heap);
entry = row_build_index_entry(row, ext, index, heap);
当继续往下走时，该事务trx_id依然是活跃的，并修改了之前的版本，检查prev_version是否需要rec在一个不同的状态（翻译自注释）
if (0 == cmp_dtuple_rec(entry, rec, offsets)) //比较构建的entry和二级索引记录是否相同，bug#65389的test case是不相同的
}else if (!rec_del) { //rec_del为false
trx = trx_get_on_id(trx_id);
继续判断如果trx_id和prev_trx_id不同，break。
1.锁的转换、加入队列、死锁判断、页面分裂时的锁迁移
2.二级索引/聚簇索引如何进行Undo log管理