首页 > 数据库 > Mysql > Mysql实现事务及扩展知识

Mysql是如何实现事务的以及相关扩展知识总结

2026-05-27 09:54:40 作者：小海獭敲代码_KD

在mysql中事务是一种机制、一个操作序列,是访问和更新数据库的程序执行单元,下面这篇文章主要介绍了Mysql是如何实现事务的以及相关扩展知识总结的相关资料,文中通过代码介绍的非常详细,需要的朋友可以参考下

最近在准备八股，整理了一些笔记，希望可以帮助到大家，有错误也希望大家指出来，大家相互学习。

实现事务靠四个核心组件：Redo log,Undo log,锁，MVCC

为什么要有这四个东西？

数据库事务要解决的核心矛盾是：

既要快（高并发）
又要稳（数据正确，宕机不丢）

如果只有一个最简单的办法：每次事务都直接改磁盘数据。那么：

改完前宕机 ——>数据损坏（需要原子性）
同时改同一行 ——>混乱（需要隔离性）
每次等磁盘——>太慢（需要性能）

于是四个组件进行分工协作：

Redo Log（重做日志）保证持久性。事务提交时，修改先写到 redolog再写磁盘数据页。其实就是把本来写磁盘的操作拆成两步
1. 先把修改内容顺序追加写到 redo log 文件（这是顺序写，极快），就认为事务提交成功了。
2. 后台慢慢把数据页刷到磁盘。
- 就算写数据页时宕机了，重启后通过重放redolog就能恢复数据。这就是经典的WAL机制。
- 总结：用“写日志代替随机写磁盘”，先保证提交速度，再异步刷盘。宕机后靠日志恢复，实现了持久性。

Undo Log (回归日志) 保证原子性。
要解决的问题：事务执行到一半要回滚，或者系统崩溃时要撤销未提交的事务，保证原子性（要么全做，要么全不做）。
1. 每次修改数据前，先把旧值（和事务 ID 等信息）存到 undo log 里。
2. 如果事务要回滚，就按 undo log 反向操作，把数据改回去。
3. 系统崩溃恢复时，发现某些事务没提交，也用 undo log 清理掉它们的修改。
- undo log 保存了数据的历史版本，这为后面的 MVCC 提供了基础。
- undo log 存了数据“修改前”的样子，让回滚和崩溃恢复能擦除未提交事务的痕迹
锁机制(行锁、间隙锁等等)保证隔离性。两个事务同时改同一行，必须一个等另一个释放锁。InnoDB的锁粒度精确到行级，还有间隙锁防止幻读。锁是“硬隔离”，强制让并发写操作排队执行，保证数据同时只能被一个人改。

MVCC保证隔离性的读写并发。
1. 利用 undo log 里保存的旧版本，让每行数据在某一时刻都有多个“快照”。
2. 每个事务在开始时，会拿到一个“快照时间点”。
3. 它读数据时，不是读最新值，而是读那个时间点之前已提交的最新版本（通过 undo log 版本链查找）。
4. 这样，一个事务在读的时候，别的事务可以随便写（产生新版本），两者互不干扰。
- 总结：MVCC 让“读”去读历史快照，“写”去创建新版本。读写不再互相等待，极大提升了并发度。
一致性不是单独实现的，它是原子性、隔离性、持久性共同作用的结果。
1. 原子性保证事务内的操作要么全生效要么全取消，不会半途而废。
2. 隔离性保证多个事务并发时，互相不会看到中间状态或造成混乱。
3. 持久性保证事务一旦提交，结果就不会丢失。
这三者共同作用，确保了数据从一个正确的状态（一致性）变到另一个正确的状态。

扩展知识

锁的类型

Redo Log(重做日志)的工作原理

InnoDB修改数据时不会直接写到磁盘上的数据页，那样随机I/O太多，性能太差。他用的WAL策略：先把修改内容顺序追加到redo log(这是顺序写极快)，后台再找机会把数据页刷到磁盘。

redo log 采用循环写的方式，有两个指针：write pos 表示当前写到哪了，checkpoint表示已经刷盘的位置。两个指针之间就是待刷盘的脏数据

+---+---+---+---+
| 0 | 1 | 2 | 3 |   redo log 文件组
+---+---+---+---+
    ^       ^
    |       |
checkpoint  write_pos

事务提交时，redo log必须落盘，这个行为由innodb_flush_log_at_trx_commit控制：

设成1：每次提交都刷盘，最安全但性能最差
设成0：每秒刷一次，宕机可能丢1秒数据
设成2：写到操作系统缓存，Mysql挂了数据还在，机器挂了才丢

Undo Log(回滚日志)与版本链

每条数据都有两个隐藏字段:trx_id记录最后修改这条数据的事务ID，roll_pointer指向undolog里的上一个版本。多次修改就会形成一条版本链。假设原始数据name='张三'，事务100改成'李四'，事务200又改成'王五':

当前数据页：name='王五', trx_id=200, roll_pointer →
    undo log：name='李四', trx_id=100, roll_pointer →
        undo log：name='张三', trx_id=0, roll_pointer=null

MVCC读数据时，根据事务的ReadView沿着版本链往回找，找到第一个自己能看见的版本。可重复读隔离级别下;ReadView在事务开始时生成一次，后面一直用这个。读已提交隔离级别下，每次查询都生成新的ReadView.

锁的实现细节

InnoDB的行锁实际上是加在索引上的，不是加在数据行上的。如果SQL没走索引，就会锁全表。

-- 假设 id 是主键，name 无索引
begin;
update user set age = 20 where id = 1;     -- 只锁 id=1 这一行
update user set age = 20 where name = '张三'; -- 锁全表！
commit;

InnoDB有三种行锁:

Record Lock(记录锁):锁单条记录,通常在通过唯一索引(如主键ID)进行等值查询并加锁时触发
Gap Lock(间隙锁):锁一个区间,不锁定记录本身,而是锁定索引记录之间的间隙,通常在可重复读隔离级别下,通过范围查询或非唯一索引查询时触发;防止幻读.他确保在你的事务执行期间,其他事务不能在这个间隙中"插入"新数据
Next - Key Lock : Record Lock + Gap Lock,锁记录和他前面的间隙

可重复读隔离级别下默认用Next-Key Lock,就是为了防幻读

锁类型	锁定对象	包含记录本身？	主要目的
Record Lock	单个索引记录	是	防止修改/删除
Gap Lock	索引之间的间隙	否	防止插入（解决幻读）
Next-Key Lock	记录 + 记录前的间隙	是	结合两者优点，默认锁定方式

面试官追问

MVCC能解决幻读吗?

回答:能解决快照读的幻读，解决不了当前读的幻读。快照读就是普通的select，走MVCC版本链，事务开始时的ReadView定死了能看到哪些数据，后面别人插入的新行看不见。但当前读比如 select...for update，读的是最新数据，这时候要靠间隙锁来防幻读，锁住查询范围内的间隙不让别人插入。

1. 快照读（Snapshot Read）

什么是快照读？ 就是最普通的 SELECT * FROM table WHERE ...。它不加任何锁,读取的是ReadView里的历史版本,极大地提高了查询性能.

它是怎么防幻读的？ InnoDB 使用了 MVCC（多版本并发控制）。当你开启事务后的第一次查询，系统会给你生成一个“快照”（ReadView）。就像给数据库拍了张照片，无论之后别人怎么插入新数据，你在这个事务里看到的永远是照片里的样子。
结论：在快照读下，MVCC 完美解决了幻读。你查一百次，结果都一样。

2. 当前读（Current Read）

什么是当前读？ 当你需要读取“最新版本”的数据，或者准备更新数据时，就是当前读。常见的语句有：

SELECT ... FOR UPDATE (写锁)
SELECT ... LOCK IN SHARE MODE (读锁)
INSERT / UPDATE / DELETE (这些操作在执行前都要先找准那一行的最新位置)
它为什么会有幻读风险？ 当前读不看“照片”，它要看“真人”。如果你只锁住了已有的 5 行记录，而没管记录之间的“空隙”，别人就能在空隙里插进第 6 行。当你再次执行当前读时，就会发现多出了一行。
它是怎么解决的？ 靠 Gap Lock（间隙锁）。它不仅锁住已有的行，还把行与行之间的“坑”也占了，不准别人蹲坑（插入）。
结论：在当前读下，MVCC 帮不上忙，必须靠间隙锁来解决幻读。

3. 最容易搞混的“幻读”场景（面试高频）

虽然上面说 MVCC 解决了快照读的幻读，但有一种特殊操作会让 MVCC “破功”，让你看到幻象：

场景演示：

事务 A：先用“快照读”查 id=5 的记录，结果是不存在的。
事务 B：插了一条 id=5 的记录并提交。
事务 A：如果此时再 SELECT，依然查不到（快照保护）。但是，如果事务 A 此时执行 UPDATE table SET name='new' WHERE id=5，这个 UPDATE 是“当前读”，它能看到事务 B 提交的那行。
结果：UPDATE 成功了，事务 A 发现自己居然更新了一条“不存在”的记录！此时再 SELECT，id=5 的记录就变出来了。

这就是所谓的“快照读下的幻读”： 因为你的事务里发生了一次“写操作”（当前读），强行更新了版本号，导致那条新纪录在你的 ReadView 里变现了。

普通的SELECT是快照读(不带 for UPDATE 或 LOCK IN SHARE MODE)
所有的修改操作都是当前读

undo log 什么时候会被清理?

回答:undolog不是事务提交就能删的，要等没有事务需要用到这些旧版本了才能清理。purge线程会扫描系统里活跃的事务，找到最老的ReadView，比它还老的undolog才能删除。所以长事务会导致undo log堆积，这也是为什么要避免长事务。

为什么redo log 要用循环写而不是一直追加?

回答:redolog的作用是崩溃恢复，checkpoint之前的日志对应的数据页已经刷盘了，这部分日志就没用了，可以覆盖掉复用空间。一直追加的话磁盘会被撑爆。而且redolog大小固定有个好处，连续的磁盘空间顺序写性能更好。binlog是一直追加的，因为它要用于主从复制和数据恢复，历史记录不能丢。

总结

到此这篇关于Mysql是如何实现事务的以及相关扩展知识总结的文章就介绍到这了,更多相关Mysql实现事务及扩展知识内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

您可能感兴趣的文章:

php结合mysql与mysqli扩展处理事务的方法