🧠 概念

事务是一组操作的集合，它是一个不可分割的工作单位。事务会把所有的操作作为一个整体一起向系统提交或撤销操作请求，即这些操作 要么同时成功，要么同时失败。

🔄 事务控制语句

开启事务

1

start transaction；

提交事务

1

commit;

回滚事务

1

rollback;

⚙️ 四大特性

• 原子性（Atomicity）：事务是不可分割的最小单元，要么全部成功，要么全部失败
• 一致性（Consistency）：事务完成时，必须使所有的数据都保持一致状态
• 隔离性（lsolation）：数据库系统提供的隔离机制，保证事务在不受外部并发操作影响的独立环境下运行
• 持久性（Durability）：事务一旦提交或回滚，它对数据库中的数据的改变就是永久的

📖 实现原理

• 持久性是通过 redo log （重做日志）来保证的
• 原子性是通过 undo log （回滚日志） 来保证的
• 隔离性是通过 MVCC（多版本并发控制） 或锁机制来保证的
• 一致性则是通过持久性+原子性+隔离性来保证

🧩 MVCC

MVCC（Multi-Version Concurrency Control，多版本并发控制）是一种并发控制机制，允许多个事务同时读取和写入数据库，而无需互相等待，从而提高数据库的并发性能。

在 MVCC 中，数据库为每个事务创建一个数据快照。每当数据被修改时，MySQL 不会立即覆盖原有数据，而是生成新版本的记录。每个记录都保留了对应的版本号或时间戳。

🔗 版本链

在 InnoDB 中，每一行数据都有两个隐藏的列：一个是 DB_TRX_ID ，另一个是 DB_ROLL_PTR 。

• DB_TRX_ID ：保存创建这个版本的事务 ID。
• DB_ROLL_PTR ：指向 undo 日志记录的指针，这个记录包含了该行的前一个版本的信息。通过这个指针，可以访问到该行数据的历史版本。

当事务更新一行数据时，InnoDB 不会直接覆盖原有数据，而是创建一个新的数据版本，并更新 DB_TRX_ID 和 DB_ROLL_PTR，使得它们指向前一个版本和相关的 undo 日志。这样，老版本的数据不会丢失，可以通过版本链找到。

📊 ReadView

ReadView（读视图）是 InnoDB 为了实现一致性读而创建的数据结构，它用于确定在特定事务中哪些版本的行记录是可见的。可以理解为数据快照

Read View 有四个重要的字段：

• m_ids ：指的是在创建 Read View 时，当前数据库中 活跃事务 的 事务 id 列表，注意是一个列表，“活跃事务”指的就是，启动了但还没提交的事务。
• min_trx_id ：指的是在创建 Read View 时，当前数据库中 活跃事务 中事务 id 最小的事务 ，也就是 m_ids 的最小值。
• max_trx_id ：这个并不是 m_ids 的最大值，而是 创建 Read View 时当前数据库中应该给下一个事务的 id 值 ，也就是全局事务中最大的事务 id 值（m_ids 的最大值） + 1；
• creator_trx_id ：指的是 创建该 Read View 的事务的事务 id 。

🔍 可见性实现

• 如果记录的 trx_id 值小于 Read View 中的 min_trx_id 值，表示这个版本的记录是在创建 Read View 前 已经提交的事务生成的，所以该版本的记录对当前事务 可见 。
• 如果记录的 trx_id 值大于等于 Read View 中的 max_trx_id 值，表示这个版本的记录是在创建 Read View 后才启动的事务生成的，所以该版本的记录对当前事务 不可见 。
• 如果记录的 trx_id 值在 Read View 的 min_trx_id 和 max_trx_id 之间，需要判断 trx_id 是否在 m_ids 列表中：
  • 如果记录的 trx_id 在 m_ids 列表中，表示生成该版本记录的活跃事务依然活跃着（还没提交事务），所以该版本的记录对当前事务不可见。
  • 如果记录的 trx_id 不在 m_ids 列表中，表示生成该版本记录的活跃事务已经被提交，所以该版本的记录对当前事务 可见 。

⚡ 快照读和当前读

💡 快照读

快照读是指事务在执行查询时，不直接读取当前最新的数据，而是读取数据的历史版本（快照）。MySQL InnoDB 通过多版本并发控制（MVCC）来实现快照读。快照读只会返回在事务开始时可见的数据，即使其他事务在之后修改了这些数据，快照读也不会受影响。

🎯 当前读

MySQL 里除了普通查询是快照读，其他都是 当前读，比如 update、insert、delete，这些语句执行前都会查询最新版本的数据，然后再做进一步的操作。

当前读是指读取数据的最新版本，并且会加锁以确保数据的一致性。即使其他事务对这个数据的修改在当前读的事务之后，这个修改也会反映在当前读的结果中。（如果事务 2 开始时间发生在事务 1 之后，那么正常情况下事务 2 的修改对事务 1 不可见，但是事务 1 的当前读可见这个修改）。

🚨 并发问题

⚠️ 脏读

定义：一个事务读取数据并且对数据进行了修改，这个修改对其他事务来说是可见的，即使当前事务没有提交。这时另外一个事务读取了这个还未提交的数据，但第一个事务突然回滚，导致数据并没有被提交到数据库，那第二个事务读取到的就是脏数据

示例：假设有 A 和 B 这两个事务同时在处理，事务 A 先开始从数据库中读取余额数据，然后再执行更新操作，如果此时事务 A 还没有提交事务，而此时正好事务 B 也从数据库中读取余额数据，那么事务 B 读取到的余额数据是刚才事务 A 更新后的数据，即使没有提交事务。

📝 不可重复读

定义：在同一事务中，读取同一数据两次，但由于其他事务的提交，读取的结果不同。

示例：假设有 A 和 B 这两个事务同时在处理，事务 A 先开始从数据库中读取余额数据，然后继续执行代码逻辑处理，在这过程中如果事务 B 更新了这条数据，并提交了事务，那么当事务 A 再次读取该数据时，就会发现前后两次读到的数据是不一致的，这种现象就被称为不可重复读。

👻 幻读

定义：在一个事务内多次查询某个符合查询条件的记录数量，如果出现前后两次查询到的记录数量不一样的情况，就意味着发生了幻读现象。

⚖️ 事务隔离级别

📊 四大隔离级别

其中 Serializable 数据安全性更好但是性能最差，Read uncommitted反之

• 读未提交（READ UNCOMMITTED）：
  • 这是最低的隔离级别，在该级别下，一个事务可以看到另一个事务尚未提交的数据修改。这可能会导致 脏读 问题，即读取到其他事务未提交的数据。
• 读已提交（READ COMMITTED）：
  • 在这个级别下，一个事务只能看到已经提交的其他事务所做的修改。这可以避免脏读问题，但是可能会引发 不可重复读 问题，即在同一个事务中，相同的查询可能返回不同的结果。
• 可重复读（REPEATABLE READ）：
  • 指一个事务执行过程中看到的数据，一直跟这个事务启动时看到的数据是一致的。在这个级别下，确保在一个事务中的多个查询返回的结果是一致的。这可以避免不可重复读问题，但是可能会引发 幻读 问题，即在同一个事务中，多次查询可能返回不同数量的行（MySQL 默认的隔离级别）。
• 串行化（SERIALIZABLE）：
  • 可串行化执行被定义为：并发执行的 SQL 事务的操作，其效果与这些 SQL 事务按某种顺序串行执行的效果相同。串行执行是指每个 SQL 事务在下一个 SQL 事务开始之前完成其全部操作
  • 这是最高的隔离级别，在这个级别下，保证事务间的操作结果相当于一个按顺序执行的单线程操作。这可以避免所有的并发问题，但是会大大降低并发性能。该级别会对记录加上读写锁，在多个事务对这条记录进行读写操作时，如果发生了读写冲突的时候，后访问的事务必须等前一个事务执行完成，才能继续执行

🔧 隔离级别的实现

🎯 读已提交

每次读取数据前都生成一个 Read_View，保证每次读操作都是最新的数据。 正是因为在读提交隔离级别下，事务每次读数据时都重新创建 Read View，那么在事务期间的多次读取同一条数据，前后两次读的数据可能会出现不一致，因为可能这期间另外一个事务修改了该记录，并提交了事务。

🔄 可重复读

可重复读隔离级别是启动事务时生成一个 Read View，然后整个事务期间都在用这个 Read View。

可重复读隔离级别下在事务期间读到的记录都是事务启动前的记录。具体过程如下

• 记录被另一个事务修改时会修改记录中的 trx_id ，同时记录的 roll_pointer 指向该记录的上一个版本的版本
• 当事务发现记录的 trx_id 被修改后根据Read_View的可见机制判断该记录是否可读
• 事务从头到尾都是使用事务启动时创建的Read_View

💻 相关SQL语句

🔍 查看事务隔离级别

1

select @@transaction isolation;

⚙️ 设置事务隔离级别

1

set [ session | global] transaction isolation level { read uncommitted | read committed | repeatable read | serializable }

📝 MySQL的日志级别

• binlog ：是 MySQL 中的二进制日志文件，用于记录 MySQL 服务器上的所有更新和修改操作。它可以记录所有的 DDL和 DML操作，包括对表结构的更改、数据的插入、修改、删除等等。 binlog 是在事务提交后生成的，因此可以用于恢复数据库。是位于 Server 层的日志

  • STATEMENT：每一条修改数据的 SQL 都会被记录到 binlog 中（相当于记录了逻辑操作，所以针对这种格式， binlog 可以称为逻辑日志），主从复制中 slave 端再根据 SQL 语句重现。但 STATEMENT 有动态函数的问题，比如你用了 uuid 或者 now 这些函数，你在主库上执行的结果并不是你在从库执行的结果，这种随时在变的函数会导致复制的数据不一致；
  • ROW：记录行数据最终被修改成什么样了（这种格式的日志，就不能称为逻辑日志了），不会出现 STATEMENT 下动态函数的问题。但 ROW 的缺点是每行数据的变化结果都会被记录，比如执行批量 update 语句，更新多少行数据就会产生多少条记录，使 binlog 文件过大，而在 STATEMENT 格式下只会记录一个 update 语句而已；
  • MIXED：包含了 STATEMENT 和 ROW 模式，它会根据不同的情况自动使用 ROW 模式和 STATEMENT 模式；

• 🔧 redo log ：用于恢复数据，保证数据的一致性和持久性。当 MySQL 发生修改时，redolog 会将这些操作记录下来，并写入磁盘。这样，当 MySQL 发生宕机或崩溃时，通过重放 redolog 就可以恢复数据。实现了事务中的 持久性 ，主要用于故障恢复；

• 🔙 undo log ：用于回滚操作。当 MySQL 发生事务回滚时，undo log 会记录这些操作并将其写入磁盘。这样，当 MySQL 需要回滚时，通过重放 undo log 就可以回滚事务。实现了事务中的 原子性 ，主要 用于事务回滚和 MVCC 。

📄 undo log

undo log （回滚日志），它保证了事务的 ACID 特性 (opens new window)事务中的原子性（Atomicity）

📖 原理

undo log 是一种用于撤销回退的日志。在事务没提交之前，MySQL 会先记录更新前的数据到 undo log 日志文件里面，当事务回滚时，可以利用 undo log 来进行回滚。

在发生回滚时，就读取 undo log 里的数据，然后做原先相反操作。比如当 delete 一条记录时， undo log 中会把记录中的内容都记下来，然后执行回滚操作的时候，就读取 undo log 里的数据，然后进行 insert 操作。

🎯 作用

• 实现事务回滚，保障事务的原子性 ：事务处理过程中，如果出现了错误或者用户执行了 ROLLBACK 语句，MySQL 可以利用 undo log 中的历史数据将数据恢复到事务开始之前的状态。
• 实现 MVCC（多版本并发控制）关键因素之一 ：MVCC 是通过 ReadView + undo log 实现的。 undo log 为每条记录保存多份历史数据，MySQL 在执行快照读（普通 select 语句）的时候，会根据事务的 Read View 里的信息，顺着 undo log 的版本链找到满足其可见性的记录。

📜 redo log

redo log 是物理日志，记录了某个数据页做了什么修改，比如对 XXX 表空间中的 YYY 数据页 ZZZ 偏移量的地方做了AAA 更新，每当执行一个事务就会产生这样的一条或者多条物理日志。通常用于保存事务已经提交但未写入磁盘的数据。

🔍 原理

在事务提交时，先将 redo log 持久化到磁盘即可。

当系统崩溃时，接着 MySQL 重启后，可以根据 redo log 的内容，将所有数据恢复到最新的状态。

⚙️ 写入方式

写入 redo log 的方式使用了追加操作， 磁盘操作是顺序写，

写入数据需要先找到写入位置，然后才写到磁盘，所以磁盘操作是随机写。MySQL 的写操作并不是立刻更新到磁盘上，而是先记录在日志上，然后在合适的时间再更新到磁盘上 。

因此MySQL 的写操作从磁盘的随机写变成了顺序写，提升语句的执行性能。

默认情况下， InnoDB 存储引擎有 1 个重做日志文件组( redo log Group），重做日志文件组由有 2 个 redo log 文件组成，这两个 redo 日志的文件名叫 ：ib_logfile0 和 ib_logfile1 。

重做日志文件组是以循环写的方式工作的，从头开始写，写到末尾就又回到开头，相当于一个环形。

所以 InnoDB 存储引擎会先写 ib_logfile0 文件，当 ib_logfile0 文件被写满的时候，会切换至 ib_logfile1 文件，当 ib_logfile1 文件也被写满时，会切换回 ib_logfile0 文件。

✅ 作用

• 实现事务的持久性：能够保证 MySQL 在任何时间段突然崩溃，重启后之前已提交的记录都不会丢失；
• 将写操作从随机写变成了顺序写 ：提升 MySQL 写入磁盘的性能。

🔗 binlog

binlog 日志是一种逻辑日志，用于记录所有事务执行的数据库的修改操作（如插入、更新、删除等），以便在需要时进行数据恢复、数据复制和数据同步等操作。

📊 作用

• 数据恢复： binlog 日志可以用于回滚到之前的某个时间点，从而恢复数据。
• 数据复制： binlog 日志可以用于在主从数据库之间复制数据，从而实现数据的高可用和负载均衡等功能

redo log和binlog的区别

• 写入方式
  • binlog 是追加写，写满一个文件，就创建一个新的文件继续写，不会覆盖以前的日志，保存的是全量的日志。
  • redo log 是循环写，日志空间大小是固定，全部写满就从头开始，保存未被刷入磁盘的脏页日志。
• 引擎类型
  • binlog 是 MySQL 的 Server 层实现的日志，所有存储引擎都可以使用；
  • redo log 是 Innodb 存储引擎实现的日志；
• 日志内容
  • binlog 是逻辑日志，记录数据库的修改操作（如插入、更新、删除等）
  • redo log 是物理日志，记录的是在某个数据页做了什么修改

🔄 主从复制

MySQL 的主从同步机制是一种数据复制技术，用于将主数据库（Master）上的数据同步到一个或多个从数据库（Slave）中。

主要是通过二进制日志（Binary Log，简称 binlog）实现数据的复制。主数据库在执行写操作时，会将这些操作记录到 binlog 中，然后推送给从数据库，从数据库重放对应的日志即可完成复制。

• 写入 Binlog：主库写 binlog 日志，提交事务，并更新本地存储数据。
  • MySQL 主库在收到客户端提交事务的请求之后，会先写入 binlog ，再提交事务，更新存储引擎中的数据，事务提交完成后，返回给客户端”操作成功”的响应。
• 同步 Binlog：把 binlog 复制到所有从库上，每个从库把 binlog 写到暂存日志中。
  • 从库会创建一个专门的 I/O 线程，连接主库的 log dump 线程，来接收主库的 binlog 日志，再把 binlog 信息写入 relay log 的中继日志里，再返回给主库”复制成功”的响应。
• 回放 Binlog：回放 binlog，并更新存储引擎中的数据。
  • 从库会创建一个用于回放 binlog 的线程，去读 relay log 中继日志，然后回放 binlog 更新存储引擎中的数据，最终实现主从的数据一致性。

🔐 二阶段提交

事务提交后， redo log 和 binlog 都要持久化到磁盘，但是这两个是独立的逻辑，可能出现半成功的状态，这样就造成主库和从库数据不一致。这是因为 redo log 影响主库的数据， binlog 影响从库的数据，所以 redo log 和 binlog 必须保持一致才能保证主从数据一致

📋 二阶段提交的过程

• 准备阶段（Prepare Phase）：在事务提交时，MySQL 的 InnoDB 引擎会先写入 redo log，并将其状态标记为prepare，表示事务已经准备提交但还未真正完成。此时的 redo log 是预提交状态，还未标记为完成提交。
• 提交阶段（Commit Phase）：当 redo log 的状态变为 prepare 后，MySQL Server 会写入 binlog（记录用户的 DML 操作）。binlog 写入成功后，MySQL 会通知 InnoDB，将 redo log 状态改为commit，完成整个事务的提交过程。

🔍 异常宕机过程

• redo log 处于 prepare 阶段，binlog 还未写入 ，此时 MySQL 异常宕机：由于 redo log 还未 commit ，所以异常恢复后， redo log 中记录的数据也不作数， binlog 内也没有记录数据，此时数据是一致的。
• redo log 处于 prepare 阶段，binlog 已写入，但 redo log 还未 commit ，此时 MySQL 异常宕机：此时对比 redo log 中 prepare 的数据和 binlog 中的数据是都一致即可。如果一致，则提交事务。不一致，则回滚事务。