被客户端工具的bug惊出一身冷汗

起因

相关运维部门需要统计数据库的一些参数，请我审核一下。当我看到MySQL这页的事务隔离级别时候当场站起来了。因为大面积的都是RR级别（REPEATABLE READ）。有关这个并不是今天的主题，我就不深入说了。其实日常使用只要记住一点就够了。这是MySQL的默认隔离级别。在这个级别下，如果事务中（比如update）表没有索引，或者的SQL没有用到索引，操作的表是表级别锁。知道这个就行了，其他的一些深入的了解其实对于日常来说用处不大。因为大部分都会设置成为RC级别（READ COMMITTED）因为很多数据库都是这样的。比如Oracle。所以也可以不用太深入了解也够用。因为你不会用，，而且非要REPEATABLE READ隔离级别的场景实在太少了。至少我没见过。

曾经在一个群中讨论哪家公司会用REPEATABLE READ这个隔离级别。大家都对这家公司开发人员比较敬佩。因为这意味着每个SQL都有用到索引。这个看似简单的要求，在我国实际上几乎做不到。

经过

然后我看到让我审核的列表有一半以上是REPEATABLE READ。我很吃惊。然后拿过一个账户登录到MySQL后台，检查了一下事务隔离级别一看是READ COMMITTED。那么可能统计错了。但是这么大面积统计错了也有点太奇怪了。请大家按照我的方式再统计一次。

结果是再次查询数据库，RR模式。在就这个很奇怪不知道时候，这时候有人反馈她查出来是RC。

对比了一下查出来RR的是workbench，而查出来RC的是Navicat。

接下来发现在workbench上如果查全局的话，查出来的也是RC。

那么问题就是workbench当前默认是RR，而全局默认是RC。这个结论解释了现状。但是我觉得不可能。

于是自己也去验证一下。并没有这种事情发生。当前会话和全局会话是一致的。

结果

我查了一下自己的workbench 8.0.24，没有问题 。而有问题的是 8.0.16

没想到还有这个问题。应该是工具问题。还好不是设置错了，否则以大部分开发来说，基本还是表锁的。这就是害怕的地方。

起因

相关运维部门需要统计数据库的一些参数，请我审核一下。当我看到MySQL这页的事务隔离级别时候当场站起来了。因为大面积的都是RR级别（REPEATABLE READ）。有关这个并不是今天的主题，我就不深入说了。其实日常使用只要记住一点就够了。这是MySQL的默认隔离级别。在这个级别下，如果事务中（比如update）表没有索引，或者的SQL没有用到索引，操作的表是表级别锁。知道这个就行了，其他的一些深入的了解其实对于日常来说用处不大。因为大部分都会设置成为RC级别（READ COMMITTED）因为很多数据库都是这样的。比如Oracle。所以也可以不用太深入了解也够用。因为你不会用，，而且非要REPEATABLE READ隔离级别的场景实在太少了。至少我没见过。

曾经在一个群中讨论哪家公司会用REPEATABLE READ这个隔离级别。大家都对这家公司开发人员比较敬佩。因为这意味着每个SQL都有用到索引。这个看似简单的要求，在我国实际上几乎做不到。

经过

然后我看到让我审核的列表有一半以上是REPEATABLE READ。我很吃惊。然后拿过一个账户登录到MySQL后台，检查了一下事务隔离级别一看是READ COMMITTED。那么可能统计错了。但是这么大面积统计错了也有点太奇怪了。请大家按照我的方式再统计一次。

结果是再次查询数据库，RR模式。在就这个很奇怪不知道时候，这时候有人反馈她查出来是RC。

对比了一下查出来RR的是workbench，而查出来RC的是Navicat。

接下来发现在workbench上如果查全局的话，查出来的也是RC。

那么问题就是workbench当前默认是RR，而全局默认是RC。这个结论解释了现状。但是我觉得不可能。

于是自己也去验证一下。并没有这种事情发生。当前会话和全局会话是一致的。

结果

我查了一下自己的workbench 8.0.24，没有问题 而有问题的是 8.0.16

没想到还有这个问题。应该是工具问题。还好不是设置错了，否则以大部分开发来说，基本还是表锁的。这就是害怕的地方。