mysql死锁问题分析

▼魔方 西西 提交于 2020-01-18 03:55:12

参考了这篇文章:http://www.cnblogs.com/LBSer/p/5183300.html  《mysql死锁问题分析

写的不错。

 

如果Mysql死锁,会报出:

 

1.1 死锁成因&&检测方法

我们mysql用的存储引擎是innodb,从日志来看,innodb主动探知到死锁,并回滚了某一苦苦等待的事务。问题来了,innodb是怎么探知死锁的?

     直观方法是在两个事务相互等待时,当一个等待时间超过设置的某一阀值时,对其中一个事务进行回滚,另一个事务就能继续执行。这种方法简单有效,在innodb中,参数innodb_lock_wait_timeout用来设置超时时间。

     仅用上述方法来检测死锁太过被动,innodb还提供了wait-for graph算法来主动进行死锁检测,每当加锁请求无法立即满足需要并进入等待时,wait-for graph算法都会被触发。

 

1.2 innodb隔离级别、索引与锁 

1.2.1 锁与索引的关系

       假设我们有一张消息表(msg),里面有3个字段。假设id是主键,token是非唯一索引,message没有索引。

id: bigint

token: varchar(30)

message: varchar(4096)

     innodb对于主键使用了聚簇索引,这是一种数据存储方式,表数据是和主键一起存储,主键索引的叶结点存储行数据。对于普通索引,其叶子节点存储的是主键值

下面介绍了几类加锁的方式。

关于主键的锁,只锁主键;

非主键的索引键,锁相关的键;

 

非索引,走的是全表扫描过滤。这时表上的各个记录都将添加上X锁。

 

 

1.2.2 锁与隔离级别的关系

为了保证并发操作数据的正确性,数据库都会有事务隔离级别的概念:

1)未提交读(Read uncommitted);2)已提交读(Read committed(RC));3)可重复读(Repeatable read(RR));4)可串行化(Serializable)。

我们较常使用的是RC和RR。(值得一提的是:大多数数据库默认的事务隔离级别是Read committed,比如Sql Server , Oracle。MySQL(其实是InnoDB,因为MyISAM不支持事务)的默认隔离级别是Repeatable read。)

 

关于Mysql的隔离级别,可以参考我的这篇文章:http://www.cnblogs.com/charlesblc/p/5913914.html

另外,补充上这篇文章写的比较清楚:http://blog.csdn.net/qq_33290787/article/details/51924963 

Read uncommitted

读未提交,顾名思义,就是一个事务可以读取另一个未提交事务的数据。(脏读)

Read committed

读提交,顾名思义,就是一个事务要等另一个事务提交后才能读取数据。

分析:这就是读提交,若有事务对数据进行更新(UPDATE)操作时,读操作事务要等待这个更新操作事务提交后才能读取数据,可以解决脏读问题。但在这个事例中,出现了一个事务范围内两个相同的查询却返回了不同数据,这就是不可重复读

Repeatable read

重复读,就是在开始读取数据(事务开启)时,不再允许修改操作。

分析:重复读可以解决不可重复读问题。写到这里,应该明白的一点就是,不可重复读对应的是修改,即UPDATE操作。但是可能还会有幻读问题。因为幻读问题对应的是插入INSERT操作,而不是UPDATE操作

Serializable 序列化

Serializable 是最高的事务隔离级别,在该级别下,事务串行化顺序执行,可以避免脏读、不可重复读与幻读。但是这种事务隔离级别效率低下,比较耗数据库性能,一般不使用。

 

另外,注意,Mysql虽然默认级别是RR,但是通过并发控制(Gap锁)有效地解决了幻读的问题。(Gap锁的内容,下面介绍)

 

为了解决幻读问题,innodb引入了gap锁。

      在事务A执行:update msg set message=‘订单’ where token=‘asd’;

      innodb首先会和RC级别一样,给索引上的记录添加上X锁,此外,还在非唯一索引’asd’与相邻两个索引的区间加上锁

       这样,当事务B在执行insert into msg values (null,‘asd',’hello’); commit;时,会首先检查这个区间是否被锁上,如果被锁上,则不能立即执行,需要等待该gap锁被释放。这样就能避免幻读问题。

 

3 死锁成因

     了解了innodb锁的基本原理后,下面分析下死锁的成因。如前面所说,死锁一般是事务相互等待对方资源,最后形成环路造成的。下面简单讲下造成相互等待最后形成环路的例子。

3.3不同索引锁冲突

     这种情况比较隐晦,事务A在执行时,除了在二级索引加锁外,还会在聚簇索引上加锁

3.4 gap锁冲突

     innodb在RR级别下,如下的情况也会产生死锁,比较隐晦。不清楚的同学可以自行根据上节的gap锁原理分析下。

 就是各种环路。注意最后,还有Gap锁造成的环路。

(具体内容看原文)

 

4 如何尽可能避免死锁

1)以固定的顺序访问表和行。比如对第2节两个job批量更新的情形,简单方法是对id列表先排序,后执行,这样就避免了交叉等待锁的情形;又比如对于3.1节的情形,将两个事务的sql顺序调整为一致,也能避免死锁。

2)大事务拆小。大事务更倾向于死锁,如果业务允许,将大事务拆小。

3)在同一个事务中,尽可能做到一次锁定所需要的所有资源,减少死锁概率。

4)降低隔离级别。如果业务允许,将隔离级别调低也是较好的选择,比如将隔离级别从RR调整为RC,可以避免掉很多因为gap锁造成的死锁。

5)为表添加合理的索引。可以看到如果不走索引将会为表的每一行记录添加上锁,死锁的概率大大增大。

 

5 如何定位死锁成因

 1)通过应用业务日志定位到问题代码,找到相应的事务对应的sql;

 2)确定数据库隔离级别。

select @@global.tx_isolation

select @@tx_isolation

3)找DBA执行下show InnoDB STATUS看看最近死锁的日志。

 (具体内容看原文)

 

(完)

 

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!