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还小，那么就不需要转换为显示锁了。