mysql中的意向锁IS,IX

mysql中的意向锁IS,IX,第1张

mysql中的意向锁IS,IX

知识储备:

  1、官方文档上说mysql是支持非锁定读的;这个功能是这样实现的,如果事务a 要对行的数据进行更新的话,那么事务a要得到行的x锁,并把这一行

     之前的样子记录在undo log里面,这样一来如果a 事务rollback 了就可以通过undo log 来恢复到之前的样子;说白了非锁定的一致性读就是读的

     行的undo log 中的内容,所以这货根本就不用上锁。


  2、在mysql中事务与锁的关系:

     1、事务开始之后申请锁。


     2、得到锁之后才进行相关的 *** 作,事务提交或回滚之后才会去释放申请到的锁。


  3、如果想要select 语句也加上s锁可以在select 后面加上lock in share mode 子句。


  4、mysql支持意向锁、意向锁是在表级别上的;

  

  5、innodb 对锁的分配方式:

     1、innodb 的锁是需要用到的时候才会去分配,并是一次性要把事务要用到的锁分配完成后才去执行事务。


     2、对锁的申请请求是放在一个队列当中的,请申请的先得到。


例子:一个lock in share mode 引起的死锁问题:

  1、准备环境:

create database tempdb;
use tempdb;
create table t(x int);
insert into t(x) values(1);

  2、事务一执行如下语句:

mysql> start transaction;
Query OK, 0 rows affected (0.00 sec) mysql> select * from t where x=1 lock in share mode;
+------+
| x |
+------+
| 1 |
+------+
1 row in set (0.00 sec)

  3、事务二执行如下语句:

mysql> start transaction;
Query OK, 0 rows affected (0.00 sec) mysql> delete from t where x=1;

  4、接着事务一又执行如下语句:

mysql> delete from t where x=1;

  5、最后mysql 监控到死锁

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

原因分析:

  1、事务一先是得到了x=1 这一行上的s 锁;

  2、事务二要去申请x=1    这一行上的x锁,由于事务一已经得到了s锁,所以它要等待事务一释放s锁。


  3、事务一又想去申请x=1  这一行上的x锁,由于事务二的申请在事务一的前面发起,所以它要等待事务二完成后才能得到。


  

  由以上分析可知,事务一,事务二产生了相互等待;进而死锁产生。


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zaji/586674.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-04-12
下一篇 2022-04-12

发表评论

登录后才能评论

评论列表(0条)

保存