当前位置：首页 > news >正文

asp室内装修装潢网站源码河源市seo点击排名软件价格

news 2025/8/23 9:37:11

asp室内装修装潢网站源码,河源市seo点击排名软件价格,东莞找工作求职招聘,wordpress主题d8今天咱们花三分钟了解下数据库中的两种读（select）操作：一致性非锁定读和一致性锁定读一致性非锁定读一致性非锁定读是什么？这里我先给出一个最最最简单的解释：一致性非锁定读就是读快照！ 快照即当前…

今天咱们花三分钟了解下数据库中的两种读（select）操作：一致性非锁定读和一致性锁定读

一致性非锁定读

一致性非锁定读是什么？这里我先给出一个最最最简单的解释：一致性非锁定读就是读快照！

快照即当前行数据之前的历史版本，每行记录可能存在多个历史版本，或者说每行记录可能有不止一个快照数据，一般我们将这种技术称为行多版本技术。而由于一个行记录可能对应着多个快照（历史版本），为此不可避免地会带来一系列的并发问题，如何解决这些并发问题，就是所谓的多版本并发控制（MVCC），当然，这不是本文的重点。

在不同事务隔离级别下，读取的方式不同。只有在事务隔离级别 READ COMMITTED 和 REPEATABLE READ（默认）下，InnoDB 存储引擎才会使用非锁定的一致性读。并且，即使都是使用非锁定的一致性读，它俩对于快照数据的定义也各不相同：

在 READ COMMITTED 事务隔离级别下，总是读取行的最新版本；如果行被锁定了，非一致性读不会因此去等待行上锁的释放，而是去读取该行版本的最新一个快照，如下图所示：
在这里插入图片描述

在 REPEATABLE READ 事务隔离级别下，对于快照数据，非一致性读总是读取事务开始时的行数据版本

这么说可能还不是很好理解，举个例子，这个时候又得掏出我们经典的 user 表了（滑稽），表中包含三个字段 id、username、age，已存在一行记录：

id = 1, username = 'Jack', age = 20;

1）第一步，我们开启一个事务，执行如下语句：

事务 1:begin;select * from user where id = 1;

2）可以看到，第一个事务并没有提交，这时，我们开启第二个事务模拟并发，执行如下语句：

事务 2:begin;update user set id = 100 where id = 1;

3）在第二个事务中，将表中 id 为 1 的记录修改为了 id=100，但是事务同样没有提交（即此时 id = 1 的行记录被事务 2 加上了行锁）。这时如果在第一个事务中再次读取 id 为 1 的记录，那显然还是 1 对吧：

事务 1:select * from user where id = 1;

在这里插入图片描述
4）接着，我们再来提交下第 2 个事务中所作的修改：

事务 2:commit;

由于当前 id = 1 的数据被修改成了 100，也就是说，当前 id = 100 的行记录拥有了一个 id = 1 的历史版本。
在这里插入图片描述
5）这个时候，再去事务 1 中读取 id 为 1 的记录，在 READ COMMITTED 和 REPEATABLE 事务隔离级别下得到结果就不一样了：

对于 READ COMMITTED 的事务隔离级别，由于事务 2 已经提交了，也就是说 id = 1 的行记录没有被事务 2 锁定，所以就会去读取该行的最新版本，即 id = 100，So，在 READ COMMITTED 的事务隔离级别下，此时查询 id = 1 的结果是 Empty Set；

而在 REPEATABLE READ 事务隔离级别下，非一致性读总是读取事务开始时的行数据版本。也就是说，在事务 1 刚开始的时候，id = 1 的数据行是什么样，现在读到的就是什么样的：
在这里插入图片描述
可以结合下面这张图来回顾下上述的过程：