MySQL InnoDB Lock Modes

雨点打透心脏的1/2处 2022-04-24 14:46 141阅读 0赞

# 行锁的S锁和X锁 #

Innodb实施标准的行级锁，其中有两种类型的锁：  
Shared lock即共享锁，S锁。如果事务对数据行r持有S锁，那么允许其它事务对数据行r持有S锁，但不允许其它事务对数据行持有X锁。  
Exclusive lock即排它锁，X锁。如果事务T1对数据行r持有X锁，那么就不允许其它事务对数据行持有S锁或X锁，除非等到T1释放r上的X锁

# 意向锁（Intention lock） #

Innodb支持多粒度锁，即允许记录锁（record locks）和表锁共存（InnoDB supports multiple granularity locking which permits coexistence of record locks and locks on entire tables）。为了在多个粒度级别上实现锁定，innodb引进了意向锁。有两种意向锁：  
Intention shared（IS）：意向共享锁，表示事务T将要对表中数据行加S锁，而先在表级别上加的就是IS锁；  
Intention exclusive（IX）：意向排它锁，表示事务T将要对表中数据行加X锁，而先在表级别上加的就是IX锁；

意图锁是表锁，它指示事务稍后将在表数据行上加何种类型的锁。IS锁表示事务稍后会在数据行上加S锁，IX锁表示事务稍后会在数据行上加X锁。常见的，像“select … lock in share mode”语句会加IS锁，“select … for update”语句会加IX锁。

所以，引入意图锁的目的就是为了支持多粒度锁定，并能通过意图锁显示事务锁定了表中的某些行，或者将要锁定表中的某些行。

意图锁的协议如下：  
一个事务要想获得行上的S锁，必须先获取该表上的IS或者更强的锁；  
一个事务要想获得行上的X锁，必须先获取该表上的IX锁。

四种锁之间的兼容性如下：  
![\_1][1]

如果事务请求的锁与现有锁兼容，则授予该事务锁；但如果与现有锁冲突，则不授予该事务锁，事务需要等待现有锁被释放后才能获取锁。

说明：  
个人认为，上面的S和X锁是表级别的S和X锁。但之前和朋友讨论，说没有表级别的S和X锁，只有行级别的S和X锁，并上面指的是行级别的S和X锁。后来发现在姜承尧的innodb内幕这本书中，也提到上面指的是行级别的S和X锁。  
因此有些疑惑的就是：锁的粒度不同，如何讨论兼容性？更何况意图锁引入的目的就是为了支持mysql的多粒度锁定。

# 死锁 #

死锁演示：  
会话1上开启事务T1:

mysql> start transaction;
    mysql> select * from ecs_payment where pay_id=2332 lock in share mode;
    +--------+----------+----------+---------+----------+-----------+------------+---------+--------+-----------+
    | pay_id | pay_code | pay_name | pay_fee | pay_desc | pay_order | pay_config | enabled | is_cod | is_online |
    +--------+----------+----------+---------+----------+-----------+------------+---------+--------+-----------+
    |   2332 | 83       | ^{}      | 4090.99 | bwlw]^k  |        13 | lb^wkw]    |       1 |      0 |         0 |
    +--------+----------+----------+---------+----------+-----------+------------+---------+--------+-----------+

会话2上开启事务T2:

mysql> start transaction;
    Query OK, 0 rows affected (0.00 sec)
    mysql> update ecs_payment set pay_name='tiatiao' where pay_id=2332;    --被卡住

会话1的事务T1再执行操作：

mysql> delete from ecs_payment where pay_id=2332;
    Query OK, 1 row affected (0.00 sec)

这时再看会话2的事务T2，会输出如下信息：

ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction

发生死锁的四个必要条件：  
互斥条件  
不可剥夺  
请求与保持  
循环等待

注意：  
如果InnoDB监视器输出的最新检测到的死锁部分包含如下输出信息：

TOO DEEP OR LONG SEARCH IN THE LOCK TABLE WAITS-FOR GRAPH, WE WILL ROLL BACK FOLLOWING TRANSACTION

这表明锁等待列表上的事务数量已经达到了200个的限制，超过200个事务的等待列表被视为死锁，这个数量限制和参数LOCK\_MAX\_DEPTH\_IN\_DEADLOCK\_CHECK有关

[1]: /images/20220214/19a5fb40fd364b84ad8659a83214637f.png