首页 › MySQL论坛 › 16. MySQL 多版本并发控制

猴多猴多嘚猴啊 發表於 2025-7-5 10:05:00

16. MySQL 多版本并发控制

<h1 id="16-mysql-多版本并发控制">16. MySQL 多版本并发控制</h1>
<p>@</p><div class="toc"><div class="toc-container-header">目录</div><ul><li>16. MySQL 多版本并发控制</li><li>1. 什么是MVCC</li><li>2. 快照读与当前读<ul><li>2.1 快照读</li><li>2.2 当前读</li></ul></li><li>3. 复习<ul><li>3.1 再谈隔离级别</li><li>3.2 隐藏字段、Undo Log版本链</li></ul></li><li>4. MVCC实现原理之ReadView<ul><li>4.1 什么是ReadView</li><li>4.2 设计思路</li><li>4.3 ReadView的规则</li><li>4.4 MVCC整体操作流程</li></ul></li><li>5. 举例说明<ul><li>5.1 READ COMMITTED隔离级别下</li><li>5.2 REPEATABLE READ隔离级别下</li><li>5.3 如何解决幻读</li></ul></li><li>6. 总结</li><li>7. 最后：</li></ul></div><p></p>
<h1 id="1-什么是mvcc">1. 什么是MVCC</h1>
<p>MVCC （Multiversion Concurrency Control），多版本并发控制。顾名思义，MVCC 是通过数据行的多个版本管理来实现数据库的 <code>并发控制 </code>。这项技术使得在InnoDB的事务隔离级别下执行 <code>一致性读</code> 操作有了保证。换言之，就是为了查询一些正在被另一个事务更新的行，并且可以看到它们被更新之前的值，这样 在做查询的时候就不用等待另一个事务释放锁。</p>
<p>MVCC没有正式的标准，在不同的DBMS中MVCC的实现方式可能是不同的，也不是普遍使用的（大家可以参考相关的DBMS文档）。这里讲解InnoDB中MVCC的实现机制（MySQL其他的存储引擎并不支持它）。</p>
<h1 id="2-快照读与当前读">2. 快照读与当前读</h1>
<p>MVCC在MySQL InnoDB中的实现主要是为了提高数据库并发性能，用更好的方式去处理 <code>读-写冲突</code> ，做到 即使有读写冲突时，也能做到 <code>不加锁</code> ， <code>非阻塞并发读</code> ，而这个读指的就是 <code>快照读</code> , 而非 <code>当前读</code> 。当前 读实际上是一种加锁的操作，是悲观锁的实现。而MVCC本质是采用乐观锁思想的一种方式。</p>
<h2 id="21-快照读">2.1 快照读</h2>
<p>快照读又叫一致性读，读取的是快照数据。<strong>不加锁的简单的 SELECT 都属于快照读</strong>，即不加锁的非阻塞 读；比如这样：</p>
<pre><code class="language-mysql">SELECT * FROM player WHERE ...
</code></pre>
<p>之所以出现快照读的情况，是基于提高并发性能的考虑，快照读的实现是基于MVCC，它在很多情况下， 避免了加锁操作，降低了开销。</p>
<p>既然是基于多版本，那么快照读可能读到的并不一定是数据的最新版本，而有可能是之前的历史版本。</p>
<p>快照读的前提是隔离级别不是串行级别，串行级别下的快照读会退化成当前读。</p>
<h2 id="22-当前读">2.2 当前读</h2>
<p>当前读读取的是记录的最新版本（最新数据，而不是历史版本的数据），读取时还要保证其他并发事务 不能修改当前记录，会对读取的记录进行加锁。加锁的 SELECT，或者对数据进行增删改都会进行当前 读。比如：</p>
<pre><code class="language-mysql">SELECT * FROM student LOCK IN SHARE MODE; # 共享锁
SELECT * FROM student FOR UPDATE; # 排他锁
INSERT INTO student values ... # 排他锁
DELETE FROM student WHERE ... # 排他锁
UPDATE student SET ... # 排他锁
</code></pre>
<h1 id="3-复习">3. 复习</h1>
<h2 id="31-再谈隔离级别">3.1 再谈隔离级别</h2>
<p>我们知道事务有 4 个隔离级别，可能存在三种并发问题：</p>
<p><img src="https://img2024.cnblogs.com/blog/3084824/202507/3084824-20250705100458739-2108135044.png"></p>
<p><img src="https://img2024.cnblogs.com/blog/3084824/202507/3084824-20250705100458758-1746110838.png"></p>
<h2 id="32-隐藏字段undo-log版本链">3.2 隐藏字段、Undo Log版本链</h2>
<p>回顾一下undo日志的版本链，对于使用 InnoDB 存储引擎的表来说，它的聚簇索引记录中都包含两个必要的隐藏列。</p>
<ul>
<li><code>trx_id</code> ：每次一个事务对某条聚簇索引记录进行改动时，都会把该事务的 <code>事务id</code> 赋值给 <code>trx_id</code> 隐藏列。</li>
<li><code>roll_pointer</code> ：每次对某条聚簇索引记录进行改动时，都会把旧的版本写入到 <code>undo日志</code> 中，然 后这个隐藏列就相当于一个指针，可以通过它来找到该记录修改前的信息。</li>
</ul>
<p><img src="https://img2024.cnblogs.com/blog/3084824/202507/3084824-20250705100458839-44780726.png"></p>
<p>假设插入该记录的<code>事务id</code>为<code>8</code>，那么此刻该条记录的示意图如下所示：</p>
<p><img src="https://img2024.cnblogs.com/blog/3084824/202507/3084824-20250705100458682-686124448.png"></p>
<blockquote>
<p>insert undo只在事务回滚时起作用，当事务提交后，该类型的undo日志就没用了，它占用的Undo Log Segment也会被系统回收（也就是该undo日志占用的Undo页面链表要么被重用，要么被释放）。</p>
</blockquote>
<p>假设之后两个事务id分别为 <code>10</code> 、 <code>20</code> 的事务对这条记录进行<code> UPDATE</code> 操作，操作流程如下：</p>
<p><img src="https://img2024.cnblogs.com/blog/3084824/202507/3084824-20250705100458720-1455566170.png"></p>
<p><img src="https://img2024.cnblogs.com/blog/3084824/202507/3084824-20250705100458759-293511729.png"></p>
<p>每次对记录进行改动，都会记录一条undo日志，每条undo日志也都有一个 <code>roll_pointer</code> 属性 （ <code>INSERT</code> 操作对应的undo日志没有该属性，因为该记录并没有更早的版本），可以将这些 <code>undo日志</code> 都连起来，串成一个链表：</p>
<p><img src="https://img2024.cnblogs.com/blog/3084824/202507/3084824-20250705100458802-1748069023.png"></p>
<p>对该记录每次更新后，都会将旧值放到一条 <code>undo日志</code> 中，就算是该记录的一个旧版本，随着更新次数 的增多，所有的版本都会被 <code>roll_pointer</code> 属性连接成一个链表，我们把这个链表称之为 <code>版本链</code> ，版 本链的头节点就是当前记录最新的值。</p>
<p>每个版本中还包含生成该版本时对应的<code>事务id</code>。</p>
<h1 id="4-mvcc实现原理之readview">4. MVCC实现原理之ReadView</h1>
<p>MVCC 的实现依赖于：<code>隐藏字段</code>、<code>Undo Log</code>、<code>Read View</code>。</p>
<h2 id="41-什么是readview">4.1 什么是ReadView</h2>
<p><img src="https://img2024.cnblogs.com/blog/3084824/202507/3084824-20250705100458778-665713709.png"></p>
<h2 id="42-设计思路">4.2 设计思路</h2>
<p>使用 <code>READ UNCOMMITTED</code> 隔离级别的事务，由于可以读到未提交事务修改过的记录，所以直接读取记录的最新版本就好了。</p>
<p>使用 <code>SERIALIZABLE</code> 隔离级别的事务，InnoDB规定使用加锁的方式来访问记录。</p>
<p>使用 <code>READ COMMITTED</code> 和 <code>REPEATABLE READ</code> 隔离级别的事务，都必须保证读到 <code>已经提交了的</code> 事务修改过的记录。假如另一个事务已经修改了记录但是尚未提交，是不能直接读取最新版本的记录的，核心问题就是需要判断一下版本链中的哪个版本是当前事务可见的，这是ReadView要解决的主要问题。</p>
<p>这个ReadView中主要包含4个比较重要的内容，分别如下：</p>
<ol>
<li>
<p><code>creator_trx_id</code> ，创建这个 Read View 的事务 ID。</p>
<blockquote>
<p>说明：只有在对表中的记录做改动时（执行INSERT、DELETE、UPDATE这些语句时）才会为 事务分配事务id，否则在一个只读事务中的事务id值都默认为0。</p>
</blockquote>
</li>
<li>
<p><code>trx_ids</code> ，表示在生成ReadView时当前系统中活跃的读写事务的 <code>事务id列表</code> 。</p>
</li>
<li>
<p><code>up_limit_id</code> ，活跃的事务中最小的事务 ID。</p>
</li>
<li>
<p><code>low_limit_id</code> ，表示生成ReadView时系统中应该分配给下一个事务的 id 值。low_limit_id 是系 统最大的事务id值，这里要注意是系统中的事务id，需要区别于正在活跃的事务ID。</p>
</li>
</ol>
<blockquote>
<p>注意：low_limit_id并不是trx_ids中的最大值，事务id是递增分配的。比如，现在有id为1， 2，3这三个事务，之后id为3的事务提交了。那么一个新的读事务在生成ReadView时， trx_ids就包括1和2，up_limit_id的值就是1，low_limit_id的值就是4。</p>
</blockquote>
<p><img src="https://img2024.cnblogs.com/blog/3084824/202507/3084824-20250705100458710-2055167821.png"></p>
<h2 id="43-readview的规则">4.3 ReadView的规则</h2>
<p>有了这个ReadView，这样在访问某条记录时，只需要按照下边的步骤判断记录的某个版本是否可见。</p>
<ul>
<li>如果被访问版本的trx_id属性值与ReadView中的 creator_trx_id 值相同，意味着当前事务在访问它自己修改过的记录，所以该版本可以被当前事务访问。</li>
<li>如果被访问版本的trx_id属性值小于ReadView中的 up_limit_id 值，表明生成该版本的事务在当前事务生成ReadView前已经提交，所以该版本可以被当前事务访问。</li>
<li>如果被访问版本的trx_id属性值大于或等于ReadView中的 low_limit_id 值，表明生成该版本的事务在当前事务生成ReadView后才开启，所以该版本不可以被当前事务访问。</li>
<li>如果被访问版本的trx_id属性值在ReadView的 up_limit_id 和 low_limit_id 之间，那就需要判断一下trx_id属性值是不是在 trx_ids 列表中。
<ul>
<li>如果在，说明创建ReadView时生成该版本的事务还是活跃的，该版本不可以被访问。</li>
<li>如果不在，说明创建ReadView时生成该版本的事务已经被提交，该版本可以被访问。</li>
</ul>
</li>
</ul>
<h2 id="44-mvcc整体操作流程">4.4 MVCC整体操作流程</h2>
<p>了解了这些概念之后，我们来看下当查询一条记录的时候，系统如何通过MVCC找到它：</p>
<ol>
<li>首先获取事务自己的版本号，也就是事务 ID；</li>
<li>获取 ReadView；</li>
<li>查询得到的数据，然后与 ReadView 中的事务版本号进行比较；</li>
<li>如果不符合 ReadView 规则，就需要从 Undo Log 中获取历史快照；</li>
<li>最后返回符合规则的数据。</li>
</ol>
<p><img src="https://img2024.cnblogs.com/blog/3084824/202507/3084824-20250705100458719-2089771035.png"></p>
<p>在隔离级别为读已提交（Read Committed）时，一个事务中的每一次 SELECT 查询都会重新获取一次 Read View。</p>
<p>如表所示：</p>
<p><img src="https://img2024.cnblogs.com/blog/3084824/202507/3084824-20250705100458694-1005174010.png"></p>
<blockquote>
<p>注意，此时同样的查询语句都会重新获取一次 Read View，这时如果 Read View 不同，就可能产生不可重复读或者幻读的情况。</p>
</blockquote>
<p>当隔离级别为可重复读的时候，就避免了不可重复读，这是因为一个事务只在第一次 SELECT 的时候会获取一次 Read View，而后面所有的 SELECT 都会复用这个 Read View，如下表所示：</p>
<p><img src="https://img2024.cnblogs.com/blog/3084824/202507/3084824-20250705100458903-1330592030.png"></p>
<h1 id="5-举例说明">5. 举例说明</h1>
<p><img src="https://img2024.cnblogs.com/blog/3084824/202507/3084824-20250705100458957-1132014571.png"></p>
<h2 id="51-read-committed隔离级别下">5.1 READ COMMITTED隔离级别下</h2>
<p><strong>READ COMMITTED ：每次读取数据前都生成一个ReadView。</strong></p>
<p>现在有两个 <code>事务id</code> 分别为 <code>10</code> 、 <code>20</code> 的事务在执行:</p>
<pre><code class="language-mysql"># Transaction 10
BEGIN;
UPDATE student SET name="李四" WHERE id=1;
UPDATE student SET name="王五" WHERE id=1;
# Transaction 20
BEGIN;
# 更新了一些别的表的记录
...
</code></pre>
<blockquote>
<p>说明：事务执行过程中，只有在第一次真正修改记录时（比如使用INSERT、DELETE、UPDATE语句），才会被分配一个单独的事务id，这个事务id是递增的。所以我们才在事务2中更新一些别的表的记录，目的是让它分配事务id。</p>
</blockquote>
<p>此刻，表student 中 id 为 1 的记录得到的版本链表如下所示：</p>
<p><img src="https://img2024.cnblogs.com/blog/3084824/202507/3084824-20250705100458714-297572483.png"></p>
<p>假设现在有一个使用 <code>READ COMMITTED</code> 隔离级别的事务开始执行：</p>
<pre><code class="language-mysql"># 使用READ COMMITTED隔离级别的事务
BEGIN;

# SELECT1：Transaction 10、20未提交
SELECT * FROM student WHERE id = 1; # 得到的列name的值为'张三'
</code></pre>
<p><img src="https://img2024.cnblogs.com/blog/3084824/202507/3084824-20250705100458784-2099916701.png"></p>
<p>之后，我们把 <code>事务id</code> 为 <code>10</code> 的事务提交一下：</p>
<pre><code class="language-mysql"># Transaction 10
BEGIN;
UPDATE student SET name="李四" WHERE id=1;
UPDATE student SET name="王五" WHERE id=1;
COMMIT;
</code></pre>
<p>然后再到 <code>事务id</code> 为 <code>20</code> 的事务中更新一下表 <code>student</code> 中 <code>id</code> 为 <code>1</code> 的记录：</p>
<pre><code class="language-mysql"># Transaction 20
BEGIN;
# 更新了一些别的表的记录
...
UPDATE student SET name="钱七" WHERE id=1;
UPDATE student SET name="宋八" WHERE id=1;
</code></pre>
<p>此刻，表student中 <code>id</code> 为 <code>1</code> 的记录的版本链就长这样：</p>
<p><img src="https://img2024.cnblogs.com/blog/3084824/202507/3084824-20250705100458719-647457729.png"></p>
<p>然后再到刚才使用 <code>READ COMMITTED</code> 隔离级别的事务中继续查找这个 id 为 1 的记录，如下：</p>
<pre><code class="language-mysql"># 使用READ COMMITTED隔离级别的事务
BEGIN;

# SELECT1：Transaction 10、20均未提交
SELECT * FROM student WHERE id = 1; # 得到的列name的值为'张三'

# SELECT2：Transaction 10提交，Transaction 20未提交
SELECT * FROM student WHERE id = 1; # 得到的列name的值为'王五'
</code></pre>
<p><img src="https://img2024.cnblogs.com/blog/3084824/202507/3084824-20250705100458720-186425277.png"></p>
<p><img src="https://img2024.cnblogs.com/blog/3084824/202507/3084824-20250705100459053-745483222.png"></p>
<h2 id="52-repeatable-read隔离级别下">5.2 REPEATABLE READ隔离级别下</h2>
<p>使用 <code>REPEATABLE READ</code> 隔离级别的事务来说，只会在第一次执行查询语句时生成一个 <code>ReadView</code> ，之后的查询就不会重复生成了。</p>
<p>比如，系统里有两个 <code>事务id</code> 分别为 <code>10</code> 、 <code>20</code> 的事务在执行：</p>
<pre><code class="language-mysql"># Transaction 10
BEGIN;
UPDATE student SET name="李四" WHERE id=1;
UPDATE student SET name="王五" WHERE id=1;
# Transaction 20
BEGIN;
# 更新了一些别的表的记录
...
</code></pre>
<p>此刻，表student 中 id 为 1 的记录得到的版本链表如下所示：</p>
<p><img src="https://img2024.cnblogs.com/blog/3084824/202507/3084824-20250705100458686-631975234.png"></p>
<p>假设现在有一个使用 <code>REPEATABLE READ</code> 隔离级别的事务开始执行：</p>
<pre><code class="language-mysql"># 使用REPEATABLE READ隔离级别的事务
BEGIN;

# SELECT1：Transaction 10、20未提交
SELECT * FROM student WHERE id = 1; # 得到的列name的值为'张三'
</code></pre>
<p><img src="https://img2024.cnblogs.com/blog/3084824/202507/3084824-20250705100458748-1266560710.png"></p>
<p>之后，我们把 <code>事务id</code> 为 <code>10</code> 的事务提交一下，就像这样：</p>
<pre><code class="language-mysql"># Transaction 10
BEGIN;

UPDATE student SET name="李四" WHERE id=1;
UPDATE student SET name="王五" WHERE id=1;

COMMIT;
</code></pre>
<p>然后再到 <code>事务id</code> 为 <code>20</code> 的事务中更新一下表 <code>student</code> 中 <code>id</code> 为 <code>1</code> 的记录：</p>
<pre><code class="language-mysql"># Transaction 20
BEGIN;
# 更新了一些别的表的记录
...
UPDATE student SET name="钱七" WHERE id=1;
UPDATE student SET name="宋八" WHERE id=1;
</code></pre>
<p>此刻，表student 中 <code>id</code> 为 <code>1</code> 的记录的版本链长这样：</p>
<p><img src="https://img2024.cnblogs.com/blog/3084824/202507/3084824-20250705100458720-539255145.png"></p>
<p>然后再到刚才使用 <code>REPEATABLE READ</code> 隔离级别的事务中继续查找这个 <code>id</code> 为 <code>1</code> 的记录，如下：</p>
<pre><code class="language-mysql"># 使用REPEATABLE READ隔离级别的事务
BEGIN;
# SELECT1：Transaction 10、20均未提交
SELECT * FROM student WHERE id = 1; # 得到的列name的值为'张三'
# SELECT2：Transaction 10提交，Transaction 20未提交
SELECT * FROM student WHERE id = 1; # 得到的列name的值仍为'张三'
</code></pre>
<p><img src="https://img2024.cnblogs.com/blog/3084824/202507/3084824-20250705100458762-1196213934.png"></p>
<p>这次<code>SELECT</code>查询得到的结果是重复的，记录的列<code>c</code>值都是<code>张三</code>，这就是<code>可重复读</code>的含义。如果我们之后再把<code>事务id</code>为<code>20</code>的记录提交了，然后再到刚才使用<code>REPEATABLE READ</code>隔离级别的事务中继续查找这个<code>id</code>为<code>1</code>的记录，得到的结果还是<code>张三</code>，具体执行过程大家可以自己分析一下。</p>
<h2 id="53-如何解决幻读">5.3 如何解决幻读</h2>
<p>接下来说明InnoDB 是如何解决幻读的。</p>
<p>假设现在表 student 中只有一条数据，数据内容中，主键 id=1，隐藏的 trx_id=10，它的 undo log 如下图所示。</p>
<p><img src="https://img2024.cnblogs.com/blog/3084824/202507/3084824-20250705100458701-252626175.png"></p>
<p>假设现在有事务 A 和事务 B 并发执行，<code>事务 A</code> 的事务 id 为 <code>20</code> ， <code>事务 B</code> 的事务 id 为 <code>30</code> 。</p>
<p>步骤1：事务 A 开始第一次查询数据，查询的 SQL 语句如下。</p>
<pre><code class="language-mysql">select * from student where id &gt;= 1;
</code></pre>
<p>在开始查询之前，MySQL 会为事务 A 产生一个 ReadView，此时 ReadView 的内容如下： <code>trx_ids= ， up_limit_id=20 ， low_limit_id=31 ， creator_trx_id=20</code> 。</p>
<p>由于此时表 student 中只有一条数据，且符合 where id&gt;=1 条件，因此会查询出来。然后根据 ReadView 机制，发现该行数据的trx_id=10，小于事务 A 的 ReadView 里 up_limit_id，这表示这条数据是事务 A 开启之前，其他事务就已经提交了的数据，因此事务 A 可以读取到。</p>
<p>结论：事务 A 的第一次查询，能读取到一条数据，id=1。</p>
<p>步骤2：接着事务 B(trx_id=30)，往表 student 中新插入两条数据，并提交事务。</p>
<pre><code class="language-mysql">insert into student(id,name) values(2,'李四');
insert into student(id,name) values(3,'王五');
</code></pre>
<p>此时表student 中就有三条数据了，对应的 undo 如下图所示：</p>
<p><img src="https://img2024.cnblogs.com/blog/3084824/202507/3084824-20250705100458932-1061235330.png"></p>
<p>步骤3：接着事务 A 开启第二次查询，根据可重复读隔离级别的规则，此时事务 A 并不会再重新生成 ReadView。此时表 student 中的 3 条数据都满足 where id&gt;=1 的条件，因此会先查出来。然后根据 ReadView 机制，判断每条数据是不是都可以被事务 A 看到。</p>
<p>1）首先 id=1 的这条数据，前面已经说过了，可以被事务 A 看到。</p>
<p>2）然后是 id=2 的数据，它的 trx_id=30，此时事务 A 发现，这个值处于 up_limit_id 和 low_limit_id 之 间，因此还需要再判断 30 是否处于 trx_ids 数组内。由于事务 A 的 trx_ids=，因此在数组内，这表 示 id=2 的这条数据是与事务 A 在同一时刻启动的其他事务提交的，所以这条数据不能让事务 A 看到。</p>
<p>3）同理，id=3 的这条数据，trx_id 也为 30，因此也不能被事务 A 看见。</p>
<p><img src="https://img2024.cnblogs.com/blog/3084824/202507/3084824-20250705100458722-928601183.png"></p>
<p>结论：最终事务 A 的第二次查询，只能查询出 id=1 的这条数据。这和事务 A 的第一次查询的结果是一样 的，因此没有出现幻读现象，所以说在 MySQL 的可重复读隔离级别下，不存在幻读问题。</p>
<h1 id="6-总结">6. 总结</h1>
<p>这里介绍了 MVCC 在 <code>READ COMMITTD</code> 、 <code>REPEATABLE READ</code> 这两种隔离级别的事务在执行快照读操作时 访问记录的版本链的过程。这样使不同事务的 <code>读-写</code> 、 <code>写-读</code> 操作并发执行，从而提升系统性能。</p>
<p>核心点在于 ReadView 的原理， <code>READ COMMITTD</code> 、 <code>REPEATABLE READ</code> 这两个隔离级别的一个很大不同 就是生成ReadView的时机不同：</p>
<ul>
<li><code>READ COMMITTD</code> 在每一次进行普通SELECT操作前都会生成一个ReadView</li>
<li><code>REPEATABLE READ</code> 只在第一次进行普通SELECT操作前生成一个ReadView，之后的查询操作都重复 使用这个ReadView就好了。</li>
</ul>
<p><img src="https://img2024.cnblogs.com/blog/3084824/202507/3084824-20250705100458796-1318975092.png"></p>
<p>通过MVCC我们可以解决：</p>
<p><img src="https://img2024.cnblogs.com/blog/3084824/202507/3084824-20250705100458801-2126574886.png"></p>
<h1 id="7-最后">7. 最后：</h1>
<blockquote>
<p>“在这个最后的篇章中，我要表达我对每一位读者的感激之情。你们的关注和回复是我创作的动力源泉，我从你们身上吸取了无尽的灵感与勇气。我会将你们的鼓励留在心底，继续在其他的领域奋斗。感谢你们，我们总会在某个时刻再次相遇。”</p>
<p><img src="https://img2024.cnblogs.com/blog/3084824/202507/3084824-20250705100459691-1984659531.gif"></p>
</blockquote><br><br>
来源：https://www.cnblogs.com/TheMagicalRainbowSea/p/18966964

查看完整版本: 16. MySQL 多版本并发控制