隐式锁

情景一

对于聚簇索引记录来说，有一个 trx_id 隐藏列，该隐藏列记录着最后改动该记录的 事务id 。那么如果在当前事务中新插入一条聚簇索引记录后，该记录的 trx_id 隐藏列代表的的就是 当前事务的 事务id ，如果其他事务此时想对该记录添加 S锁 或者 X锁 时，首先会看一下该记录的trx_id 隐藏列代表的事务是否是当前的活跃事务，如果是的话，那么就帮助当前事务创建一个 X锁 （也就是为当前事务创建一个锁结构， is_waiting 属性是 false ），然后自己进入等待状态 （也就是为自己也创建一个锁结构， is_waiting 属性是 true ）。

情景二

对于二级索引记录来说，本身并没有 trx_id 隐藏列，但是在二级索引页面的 Page Header 部分有一个 PAGE_MAX_TRX_ID 属性，该属性代表对该页面做改动的最大的 事务id ，如 果 PAGE_MAX_TRX_ID 属性值小于当前最小的活跃 事务id ，那么说明对该页面做修改的事务都已 经提交了，否则就需要在页面中定位到对应的二级索引记录，然后回表找到它对应的聚簇索引记 录，然后再重复 情景一 的做法。

session 1:

mysql> begin;

Query OK, 0 rows affected (0.00 sec) mysql> insert INTO student VALUES(34,"周八","二班");

Query OK, 1 row affected (0.00 sec)

session 2:  

mysql> begin;

Query OK, 0 rows affected (0.00 sec) mysql> select * from student lock in share mode; #执行完，当前事务被阻塞

执行下述语句，输出结果：  

mysql> SELECT * FROM performance_schema.data_lock_waits\G; *************************** 1. row ***************************                          ENGINE: INNODB

     REQUESTING_ENGINE_LOCK_ID: 140562531358232:7:4:9:140562535668584 REQUESTING_ENGINE_TRANSACTION_ID: 422037508068888

         REQUESTING_THREAD_ID: 64

           REQUESTING_EVENT_ID: 6

REQUESTING_OBJECT_INSTANCE_BEGIN: 140562535668584

       BLOCKING_ENGINE_LOCK_ID: 140562531351768:7:4:9:140562535619104 BLOCKING_ENGINE_TRANSACTION_ID: 15902

           BLOCKING_THREAD_ID: 64

             BLOCKING_EVENT_ID: 6

BLOCKING_OBJECT_INSTANCE_BEGIN: 140562535619104 1 row in set (0.00 sec)

隐式锁的逻辑过程如下

A. InnoDB的每条记录中都一个隐含的trx_id字段，这个字段存在于聚簇索引的B+Tree中。

B. 在操作一条记录前，首先根据记录中的trx_id检查该事务是否是活动的事务(未提交或回滚)。如果是活 动的事务，首先将 隐式锁 转换为 显式锁 (就是为该事务添加一个锁)。

C. 检查是否有锁冲突，如果有冲突，创建锁，并设置为waiting状态。如果没有冲突不加锁，跳到E。

D. 等待加锁成功，被唤醒，或者超时。

E. 写数据，并将自己的trx_id写入trx_id字段。

显式锁

通过特定的语句进行加锁，我们一般称之为显示加锁，

例如： 显示加共享锁：

select ....  lock in share mode

显示加排它锁：

select ....  for update