从源码分析 MySQL 死锁问题入门
这篇文章主要讲的是如何通过调试 MySQL 源码,知道一条 SQL 真正会拿哪些锁,不再抓虾,瞎猜或者何登成大神没写过的场景就不知道如何处理了
通过好多个深夜艰难的单步调试,终于找到了一个理想的断点,可以看到大部分获取锁的过程
代码在 lock0lock.c 的 static enum db_err lock_rec_lock() 函数中,这个函数会显示,获取锁的过程,以及获取锁成功与否的情况
对于之前何登成大神博客里面的内容(hedengcheng.com/?p=771), 我们来做实验逐个验证(以下介绍的都是在 RC 隔离级别下的实验)
场景 1:通过主键进行删除
表结构
可以看到,对索引 PRIMARY 加锁,mode = 1027,1027 是什么意思呢?1027 = LOCK_REC_NOT_GAP + LOCK_X(非 gap 的记录而且是 X 锁)
过程如下
结论:根据主键 id 去删除数据,且没有其它索引的情况下,此 SQL 只需要在 id = 10 这条记录上对主键索引加 X 锁即可
场景 2:通过唯一索引进行删除
表结构做了微调,增加了 name 的唯一索引
来看实际源码调试的结果 第一步:
第二步:
结论:这个过程是先对唯一键 uk_name 加 X 锁,然后再对聚簇索引(主键索引)加 X 锁
过程如下
场景 3:通过普通索引进行删除
调试过程如图:
结论:通过普通索引进行更新时,会对满足条件的所有普通索引加 X 锁,同时会对相关的主键索引加 X 锁
过程如下
场景 4:不走索引进行删除
总共有 5 把 X 锁,剩下的 3 把就不一一放上来了
结论:不走索引进行更新时,sql 会走聚簇索引(主键索引)对全表进行扫描,因此每条记录,无论是否满足条件,都会被加上 X 锁。还没完... 但是为了效率考量,MySQL 做了优化,对于不满足条件的记录,会在判断后放锁,最终持有的,是满足条件的记录上的锁,但是不满足条件的记录上的加锁/放锁动作不会省略。
过程如下
链接:https://juejin.cn/post/6844903847488569357
版权声明: 本文为 InfoQ 作者【比伯】的原创文章。
原文链接:【http://xie.infoq.cn/article/19b3a5e89ca4ec5d88d5d30ed】。文章转载请联系作者。
评论