0
点赞
收藏
分享

微信扫一扫

思考 | 执行 delete from t1 where id = 10;MySQL会加什么锁?

思考一个问题:下面一条简单的SQL,它加什么锁?

  • delete from t1 where id = 10;

带着你的答案,我们继续往下看。


如果要分析上述SQL的加锁情况,必须了解这个SQL的执行前提,MySQL的隔离级别是什么?id列是不是主键?id列有没有索引?前提不同加锁处理的方式也不同。


可能的情况:

  • id列是不是主键?
  • MySQL的隔离级别是什么?
  • id列如果不是主键,那么id列上有索引吗?
  • id列上如果有二级索引,那么这个索引是唯一索引吗?
  • SQL的执行计划是什么?索引扫描?全表扫描?

根据上述情况,有以下几种组合:

  • id列是主键,RC隔离级别
  • id列是二级唯一索引,RC隔离级别
  • id列是二级非唯一索引,RC隔离级别
  • id列上没有索引,RC隔离级别
  • id列是主键,RR隔离级别
  • id列是二级唯一索引,RR隔离级别
  • id列是二级非唯一索引,RR隔离级别
  • id列上没有索引,RR隔离级别

问题看起来变得复杂了,事实上,要分析加锁,就得考虑这么多情况,不过只要你选定了一种组合,SQL需要加哪些锁,其实也就确定了。


聊一聊几个比较经典的组合:

组合一:id主键+RC

大部分系统都是Read Committed隔离级别,id列是主键,这种情况只需要将主键上,id = 10的记录加上X锁即可。见下图:

思考 | 执行 delete from t1 where id = 10;MySQL会加什么锁?_主键



结论:id是主键时,此SQL只需要在id=10这条记录上加X锁即可。

组合二:id唯一索引+RC

id是一个Unique的二级索引键值。那么在RC隔离级别下,delete from t1 where id = 10; 需要加什么锁呢?


见下图:

思考 | 执行 delete from t1 where id = 10;MySQL会加什么锁?_主键_02



name列是主键,id列是唯一索引。此时,加锁的情况由于组合一有所不同。由于id是唯一索引,因此delete语句会选择走id列的索引进行where条件的过滤,在找到id=10的记录后,首先会将唯一索引上的id=10索引记录加上X锁,同时,会根据读取到的name列,回主键索引,然后将聚簇索引上的name = ‘d’ 对应的主键索引项加X锁。


结论:若id列上有唯一索引。那么SQL需要加两个X锁,一个对应于id唯一索引上的id = 10的记录,另一把锁对应于聚簇索引上的[name=’d’,id=10]的记录

组合三:id非唯一索引+RC

id列只有一个普通的索引,那么此时会持有哪些锁?


见下图:

思考 | 执行 delete from t1 where id = 10;MySQL会加什么锁?_主键_03



首先,id列索引上,满足id = 10查询条件的记录,均已加锁。同时,这些记录对应的主键索引上的记录也都加上了锁。与组合二唯一的区别在于,组合二最多只有一个满足等值查询的记录,而组合三会将所有满足查询条件的记录都加锁。


结论:若id列上有非唯一索引,那么对应的所有满足SQL查询条件的记录,都会被加锁。同时,这些记录在主键索引上的记录,也会被加锁。

组合四:id无索引+RC

id列上没有索引,where id = 10;这个过滤条件,没法通过索引进行过滤,那么只能走全表扫描做过滤。对应于这个组合,SQL会加什么锁?


见下图:

思考 | 执行 delete from t1 where id = 10;MySQL会加什么锁?_加锁_04



由于id列上没有索引,因此只能走聚簇索引,进行全部扫描。从图中可以看到,满足删除条件的记录有两条,但是,聚簇索引上所有的记录,都被加上了X锁。无论记录是否满足条件,全部被加上X锁。既不是加表锁,也不是在满足条件的记录上加行锁。有人可能会问?为什么不是只在满足条件的记录上加锁呢?这是由于MySQL的实现决定的。如果一个条件无法通过索引快速过滤,那么存储引擎层面就会将所有记录加锁后返回,然后由MySQL Server层进行过滤。因此也就把所有的记录,都锁上了。


结论:若id列上没有索引,SQL会走聚簇索引的全扫描进行过滤,由于过滤是由MySQL Server层面进行的。因此每条记录,无论是否满足条件,都会被加上X锁。但是,为了效率考量,MySQL做了优化,对于不满足条件的记录,会在判断后放锁,最终持有的,是满足条件的记录上的锁,但是不满足条件的记录上的加锁/放锁动作不会省略。同时,优化也违背了2PL的约束。


面的四个组合,都是在Read Committed隔离级别下的加锁行为,接下来的四个组合,是在Repeatable Read隔离级别下的加锁行为。

组合五:id主键+RR

id列是主键列,Repeatable Read隔离级别,针对delete from t1 where id = 10; 这条SQL,加锁与组合一:[id主键,Read Committed]一致。

组合六:id唯一索引+RR

组合六的加锁,与组合二:[id唯一索引,Read Committed]一致。两个X锁,id唯一索引满足条件的记录上一个,对应的聚簇索引上的记录一个。

组合七:id非唯一索引+RR

在RR隔离级别下,为了防止幻读的发生,会使用Gap锁。这里,你可以把Gap锁理解为,不允许在数据记录前面插入数据。对应于这个组合,SQL会加什么锁?


见下图:

思考 | 执行 delete from t1 where id = 10;MySQL会加什么锁?_加锁_05



结论:Repeatable Read隔离级别下,id列上有一个非唯一索引,对应SQL:delete from t1 where id = 10; 首先,通过id索引定位到第一条满足查询条件的记录,加记录上的X锁,加GAP上的GAP锁,然后加主键聚簇索引上的记录X锁,然后返回;然后读取下一条,重复进行。直至进行到第一条不满足条件的记录[11,f],此时,不需要加记录X锁,但是仍旧需要加GAP锁,最后返回结束。什么时候会取得gap lock或nextkey lock 这和隔离级别有关,只在REPEATABLE READ或以上的隔离级别下的特定操作才会取得gap lock或nextkey lock。

组合八:id无索引+RR

Repeatable Read隔离级别下的最后一种情况,id列上没有索引。此时SQL:delete from t1 where id = 10; 没有其他的路径可以选择,只能进行全表扫描。最终的加锁情况,见下图:

思考 | 执行 delete from t1 where id = 10;MySQL会加什么锁?_加锁_06



结论:在Repeatable Read隔离级别下,如果进行全表扫描的当前读,那么会锁上表中的所有记录,同时会锁上聚簇索引内的所有GAP,杜绝所有的并发 更新/删除/插入 操作。当然,也可以通过触发semi-consistent read,来缓解加锁开销与并发影响,但是semi-consistent read本身也会带来其他问题,不建议使用。

总结

本文对MySQL一些基础性的知识点进行了详细的总结,参考了网上和书上比较多的资料和实例。希望能对各位的学习有所帮助。

举报

相关推荐

0 条评论