两个小工具,MySQL死锁分析,新技能又Get!
第二部分,关键词是:
通过show engine innodb status; 能够看到很多事务与锁之间的信息,对分析问题十分有帮助,这些信息,能够解释一些问题,但仍有两个疑惑: (1)事务1为啥想拿55555555555的锁? 画外音:这正是,事务1被阻塞的原因。 (2)事务2为啥想拿11111111111的锁?死锁的发生,说明事务1此时真占着11111111111的锁,这又是为什么呢? 画外音:第一个事务占111抢555,第二个事务占555抢111,循环嵌套,才会死锁。 工具二:
为了进一步寻找原因,可以通过explain看下导致死锁语句的执行计划。
(1) select_type:SIMPLE 这是一个简单类型的SQL语句,不含子查询或者UNION。 (2) type:index 访问类型,即找到所需数据使用的遍历方式,潜在的方式有:
上述扫描方式,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,基本已经可以判断:
并没有和我们预想一样,走cell索引进行查询,而是走了PK索引进行了全表扫描。 再仔细一看:
建表的时候cell定义的是字符串类型。 而更新的时候,
使用的是整数类型。 类型转换,会导致全表扫描,出现锁升级,锁住全部记录。 加上引号,再次通过explain验证一下:
果然印证了猜想:
这下全部可以解释了。 总结 就本例而言:需要注意字符串与整数之间的强制类型转换,有时候少一个引号,就会使得行锁升级为表锁。 死锁是MySQL中非常难调试的问题,常见的思路与方法有:
思路比结论更重要,希望大家有收获。 【本文为51CTO专栏作者“58沈剑”原创稿件,转载请联系原作者】 ![]() 戳这里,看该作者更多好文 (编辑:晋中站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |