MySQL InnoDB Lock Modes

  1. 云栖社区>
  2. 袋鼠云技术团队>
  3. 博客>
  4. 正文

MySQL InnoDB Lock Modes

未央& 2019-03-31 20:49:04 浏览1448
展开阅读全文

行锁的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

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

说明:
个人认为,上面的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有关

网友评论

登录后评论
0/500
评论
未央&
+ 关注
所属团队号: 袋鼠云技术团队