两个小工具，MySQL死锁分析，新技能又Get！

第二部分，关键词是：

• Transaction 2，事务3999;
• 正在执行

update t set cell=456 where cell=55555555555; 

• 持有锁(holds the lock)，记录锁(record locks)，主键索引上(index primary)，互斥锁(lock_mode X)，物理记录(physical record)，asc 55555555555;
• 正在等待锁释放(waiting for this lock to be granted)，记录锁(record locks)，主键索引上(index primary)，互斥锁(lock_mode X)，物理记录(physical record)，asc 11111111111;
• 事务2回滚(we roll back transaction 2);

通过show engine innodb status; 能够看到很多事务与锁之间的信息，对分析问题十分有帮助，这些信息，能够解释一些问题，但仍有两个疑惑：

(1)事务1为啥想拿55555555555的锁?

画外音：这正是，事务1被阻塞的原因。

(2)事务2为啥想拿11111111111的锁?死锁的发生，说明事务1此时真占着11111111111的锁，这又是为什么呢?

画外音：第一个事务占111抢555，第二个事务占555抢111，循环嵌套，才会死锁。

工具二：

explain 

为了进一步寻找原因，可以通过explain看下导致死锁语句的执行计划。

explain update t set cell=456 where cell=55555555555; 

(1) select_type：SIMPLE

这是一个简单类型的SQL语句，不含子查询或者UNION。

(2) type：index

访问类型，即找到所需数据使用的遍历方式，潜在的方式有：

• ALL(Full Table Scan)：全表扫描;
• index：走索引的全表扫描;
• range：命中where子句的范围索引扫描;
• ref/eq_ref：非唯一索引/唯一索引单值扫描;
• const/system：常量扫描;
• NULL：不用访问表;

上述扫描方式，ALL最慢，逐步变快，NULL最快。

怀疑点1：明明cell字段有uniq索引，为何要进行走PK索引的全表扫描呢?

(3) possible_keys：NULL

可能在哪个索引找到记录。

(4) key：PRIMARY

实际使用索引。

画外音：使用PK进行的全表扫描。

(5) ref：NULL

哪些列，或者常量用于查找索引上的值。

怀疑点2：where条件中的查询条件55555555555，本来应该作为在索引上被检索的值呀?

(6) rows：5

找到所需记录，预估需要读取的行数。

怀疑点3：明明修改的是5，为何初始化的1，2，3，以及第一个事务插入的4，以及第二个事务插入的5，都要被读取呢?不应该全表扫描呀。

通过explain，基本已经可以判断：

update t set cell=456 where cell=55555555555; 

并没有和我们预想一样，走cell索引进行查询，而是走了PK索引进行了全表扫描。

（编辑：西安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!