一个简单的方式看看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的机制特殊，就是要有间隙锁，而没索引时候这个间隙就扩大到表的全部数据了，即全表的数据都被锁定了。