一个简单的方式看看MySQL的锁
突然发现半个月没写了。最近事情太多了。
在日常工作的处理问题的过程中，我发现了一个简单的论证锁的问题，以前我讲的有点复杂，看来应该去改改之前的讲法了。
首先构造一个无主键无索引的表。并且初始化5条数据。
场景A： RR隔离级别下， 无where条件的update， 这种的update操作由于没有带where条件，我说是对全表进行更新应该没有争议吧？那么全表更新的操作说是对每一行发生锁定应该没有争议吧。可以看到这个事务号是8801.
++++++++
然后查询data_locks 。可以看到8801事务，锁定了0X000000000500开始的5行数据。
该场景结论：
场景B： RR隔离级别下， 有where条件的update， 这种的update操作由于带where条件，我们来看看是锁定一行还是两行，或者是全表的每一行。可以看到这个事务号是8802.
然后查询data_locks 。可以看到8802事务，锁定了0X000000000500开始的5行数据。
该场景结论：
从data_locks的输出结果来看。 带不带where条件的 是等价的。
场景C： RC隔离级别下， 无where条件的update， 这种的update操作由于没有带where条件，我说是对全表进行更新应该没有争议吧？那么全表更新的操作说是对每一行发生锁定应该没有争议吧。可以看到这个事务号是8803.
然后查询data_locks 。可以看到8803事务，锁定了0X000000000500开始的5行数据。
该场景结论：
最后是场景D RC隔离级别下， 有where条件的update， 这种的update操作由于带where条件，没有争议的是锁定一行。可以看到这个事务号是8804.
然后查询data_locks 。可以看到8804事务，锁定了0X000000000501的1行数据。
所有场景结论：RR下没有索引的update和没有带where条件的锁定行数是一样的（全表）。因为RR的机制特殊，就是要有间隙锁，而没索引时候这个间隙就扩大到表的全部数据了，即全表的数据都被锁定了。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/637517/viewspace-3017818/ ，如需转载，请注明出处，否则将追究法律责任。
下一篇：
AP的数据库性能到底重要吗？
请登录后发表评论
登录
全部评论
