MySQL事务处理：如何确保数据一致性与可靠性

一、关于事务

1.1 简介

事务（Transaction）是数据库管理系统（DBMS）中的一个核心概念。MySQL 事务是指一组数据库操作，作为一个整体进行处理，确保要么全部成功，要么全部失败。

事务可以保证数据库的一致性、隔离性、持久性，避免在多个操作中出现部分成功、部分失败的情况。MySQL 使用 ACID 属性来保证事务的正确性和稳定性。

​

思考：我去银行给朋友汇款，我卡上有100元，朋友卡上50元。我给朋友转账50元，如果我的钱刚扣，而朋友的钱又没加时，网线断了, 怎么办?

e8c7ec31-c0eb-45b5-87ea-d99ccd2552a2

​

‍

1.2 发展

数据库事务的概念与技术发展经历了多个阶段，随着计算机科学和数据库技术的进步，事务管理系统也不断演化。以下是数据库事务发展历程的主要阶段：

1. 事务概念的提出（1970年代）

事务的概念最早可以追溯到20世纪70年代，随着关系型数据库理论的提出而逐步发展。E.F. Codd 在其关系模型的论文中，强调了数据库需要支持一致性和完整性。数据库事务概念的初步提出是为了解决数据库操作的原子性和一致性问题，尤其是在多用户并发环境下如何保证数据的正确性。

5e66fbcb-6daf-4476-8230-776fb4471862

​

E.F. Codd

• ACID 属性的提出： 在1970年代后期，Jim Gray 和其他学者进一步提出了事务的四个重要属性，即 ACID（原子性、Consistency、一致性、隔离性、Durability）属性。这一理论为事务处理和数据库管理系统（DBMS）的发展奠定了基础。

0e73adf6-ba61-427a-89d4-ab442de82ce2

​

Jim Gray

‍

2. 早期的数据库事务处理（1970年代至1980年代初期）

在70年代末到80年代初期，随着关系型数据库管理系统的逐步推广，事务的管理开始成为一个重要的研究方向和实践需求。早期的数据库系统，如 IBM's DB2、Ingres 和 Oracle，开始加入事务处理功能。

• 两阶段提交协议（2PC） ： 为了实现分布式数据库系统中的事务一致性，两阶段提交协议（2PC） 在20世纪80年代初期得到了广泛应用。该协议确保了分布式系统中的所有节点都要么完成提交，要么全部回滚，避免了部分提交导致的数据不一致问题。
• 回滚与日志： 早期的数据库系统使用事务日志（如Undo Log）来实现事务回滚和恢复。事务的操作会先写入日志，确保即使系统崩溃，也可以根据日志回滚到一致性状态。

‍

3. 事务隔离和锁机制的发展（1980年代至1990年代）

随着并发控制的需求日益增加，事务隔离级别的设计和实现成为数据库管理系统中的重要组成部分。

• 事务隔离级别： 事务的隔离性（即一个事务的操作不应被其他事务看到）是数据库中最具挑战的部分之一。在这个阶段，事务的隔离级别（如读未提交、读已提交、可重复读、串行化）逐渐成为数据库事务设计的关键部分。每个隔离级别会在不同的性能和数据一致性之间进行权衡。
• 锁机制的演进： 锁机制（如行级锁、表级锁）成为控制并发事务访问的主要手段。随着事务管理的复杂化，行级锁（而非表级锁）的使用逐渐增加，以提高并发性能。
• 多版本并发控制（MVCC） ： 在这一时期，多版本并发控制（MVCC） 技术得到了发展，尤其是在PostgreSQL 和MySQL InnoDB 存储引擎中得到应用。MVCC 允许多个事务并行执行，每个事务可以看到数据的不同版本，避免了锁竞争，提高了并发性。

‍

4. 分布式事务和复杂事务模型（1990年代至2000年代初期）

随着互联网和分布式计算的快速发展，数据库事务的处理面临着更大的挑战。事务不仅需要在单一数据库内保证一致性，还需要在跨数据库或跨节点的分布式环境中进行协调。

• 分布式事务的挑战： 分布式系统中的事务往往涉及多个数据库或服务节点。在这一阶段，分布式事务协议，如两阶段提交协议（2PC） 和 三阶段提交协议（3PC） 开始被应用，以保证不同系统间的事务一致性。然而，分布式事务面临着网络延迟、故障恢复和一致性等问题。
• 最终一致性： 随着分布式系统的普及，传统的强一致性模型（如ACID）开始出现挑战。为了解决性能和可扩展性问题，分布式系统中出现了最终一致性的概念。它不要求每次操作都必须是强一致的，而是通过异步更新和协调机制来最终达到一致性。

‍

5. 事务的现代化与微服务架构（2000年代中期至今）

随着云计算和微服务架构的广泛采用，数据库事务在架构上经历了进一步的演变，特别是在大规模分布式系统和无服务器架构下。

• 微服务中的事务管理： 在微服务架构中，传统的单一数据库事务变得难以使用，因为每个微服务可能使用不同的数据库或存储方式。为了解决这个问题，出现了如 Saga 模式 和 事件驱动架构 等新型事务管理模式。这些模式通过分布式的异步事务和补偿事务来确保系统的一致性和可靠性。
  • Saga 模式： Saga 模式是一种长事务的管理方式，它将一个大事务分解为多个小的子事务，并通过补偿机制来确保最终的一致性。这种模式通常采用异步通信，通过事件或消息队列传递事务状态。
  • 事件驱动架构： 事件驱动架构（EDA）通过触发和响应事件的方式管理分布式事务。在这种架构下，系统的状态变化通过事件流传播，保证了系统的高可用性和一致性。
• NoSQL 数据库与事务的挑战： 随着 NoSQL 数据库（如 Cassandra、MongoDB 等）的出现，传统关系型数据库的事务模型受到挑战。很多 NoSQL 数据库放宽了 ACID 属性，采用了更为灵活的事务模型，如 BASE（Basically Available, Soft state, Eventually consistent）模型。这使得系统在高可扩展性和高可用性的情况下，可以牺牲一些强一致性。

‍

6. 事务的未来发展趋势

数据库事务的研究与技术发展依然在不断进步，以下是一些未来的趋势：

• 分布式事务的标准化：随着 分布式数据库 和 微服务架构 的普及，分布式事务的标准化和协议化仍然是一个重要的研究方向。现有的协议（如 2PC、3PC、TCC）以及新兴的方案（如 CAP 定理 和 一致性哈希）将不断优化，解决网络延迟和一致性问题。
• 增强型事务管理：新一代的数据库系统将集成更多的智能算法来自动优化事务处理，减少锁争用，提高并发性，提升事务的执行效率。
• 混合事务模式：结合传统的 ACID 事务和现代的最终一致性模型，开发新的混合事务模型，以在保证数据一致性的同时，优化大规模分布式系统的性能。
• 无服务器架构和边缘计算中的事务：随着 无服务器计算 和 边缘计算 的流行，如何在去中心化、低延迟的环境下处理事务也将成为一个研究热点。

‍

1.3 特点功能

1.3.1 事务的必要性

• 数据完整性: 确保所有相关的数据更改都一致。
• 并发控制: 处理多个用户同时访问数据库时的数据一致性。
• 故障恢复: 在出现错误时，能够恢复到事务开始前的状态。

‍

1.3.2 基本特性（ACID）

为了保证事务的可靠性，MySQL 遵循 ACID 原则，即原子性、一致性、隔离性和持久性：

• 原子性 (Atomicity) : 事务中的所有操作要么全部执行成功，要么全部不执行。若事务中的任何操作失败，之前的所有操作都会被撤销（回滚）。
• 一致性 (Consistency) : 事务执行前后，数据库都应处于一致的状态。即所有的数据变更都必须符合预定的规则和约束。
• 隔离性 (Isolation) : 并发执行的事务之间应相互隔离，事务的执行不应受到其他事务的干扰。MySQL 提供不同的隔离级别，以平衡并发性和一致性。
• 持久性 (Durability) : 一旦事务成功提交，其结果应持久保存，即使系统发生故障，已提交的数据也不会丢失。

其中：原子性和一致性由undolog实现；隔离性由mvcc实现；持久性由redeolog实现 举个例子： A向B转账500，转账成功，A扣除500元，B增加500元，原子操作体现在要么都成功，要么都失败 在转账的过程中，数据要一致，A扣除了500，B必须增加500 在转账的过程中，隔离性体现在A向B转账，不能受其他事务干扰 在转账的过程中，持久性体现在事务提交后，要把数据持久化（可以说是落盘操作）

‍

1.3.3 隔离级别

MySQL 允许设置事务的隔离级别，以控制事务之间的相互影响。隔离级别决定了一个事务对其他事务操作的可见性和干扰程度。MySQL 支持以下四种隔离级别：

• 读未提交（Read Uncommitted） ： 在这个级别，事务可以读取未提交事务的数据。容易导致脏读（dirty read）问题，即一个事务可以读取另一个事务尚未提交的未保存数据。
• 读已提交（Read Committed） ： 在这个级别，事务只能读取已提交事务的数据。避免了脏读问题，但仍然可能会遇到不可重复读（non-repeatable read）问题，即同一个查询在不同时间读取到不同的结果。
• 可重复读（Repeatable Read） ： 在这个级别，事务在整个过程中读取的数据是稳定的，不会受到其他事务的影响。MySQL 的 InnoDB 存储引擎默认使用此级别，它能够避免脏读和不可重复读问题，但可能会导致幻读（phantom read）问题。
• 串行化（Serializable） ： 这是最严格的隔离级别，所有事务按照顺序执行，避免了脏读、不可重复读和幻读问题，但性能较低，因为事务间的并发性几乎完全被限制。

‍

你可以通过以下 SQL 查询当前事务的隔离级别：

SELECT @@transaction_isolation;

image

​

‍

你也可以设置事务的隔离级别，使用以下语句：

SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;

‍

1.3.4 锁机制

MySQL 事务中，锁是确保数据一致性和隔离性的关键。MySQL 支持多种类型的锁，常见的锁有：

• 共享锁（S锁，Shared Lock） ： 允许事务读取数据，但不允许其他事务修改该数据。多个事务可以同时对同一数据加共享锁。
• 排他锁（X锁，Exclusive Lock） ： 允许事务对数据进行修改，其他事务不能对该数据加共享锁或排他锁。
• 行级锁（Row-level Lock） ： InnoDB 存储引擎支持行级锁，它只锁定操作数据的行。行级锁比表级锁更细粒度，能提供更高的并发性。
• 表级锁（Table-level Lock） ： 锁定整个表，操作期间其他事务不能访问该表的任何数据。表级锁的粒度较粗，性能开销较大，通常在 MyISAM 存储引擎中使用。

‍

1.3.5 事务日志

MySQL 使用事务日志来保证数据的持久性和恢复能力。常见的日志包括：

• redo log（重做日志）： 用于记录事务的修改操作。当系统崩溃时，MySQL 可以通过 redo log 恢复未提交但已写入磁盘的数据。
• binlog（二进制日志）： 用于记录所有修改数据库的操作，它主要用于数据的复制（Replication）和恢复。binlog 是 MySQL 高可用架构中非常重要的组成部分。

‍

1.3.6 自动提交与事务

在 MySQL 中，默认情况下，每个 SQL 语句都是一个独立的事务。当执行一个 SQL 语句时，它会自动提交（即自动执行 COMMIT​）。但是，如果你显式地使用 START TRANSACTION​ 或 BEGIN​ 开始事务，则需要显式地使用 COMMIT​ 或 ROLLBACK​ 来提交或回滚事务。

如果要关闭自动提交，可以使用以下语句：

SET autocommit = 0;

要启用自动提交，可以使用：

SET autocommit = 1;

‍

• 显式事务控制：用户可以通过START TRANSACTION​或BEGIN​语句显式地开始一个事务，使用COMMIT​提交事务，或者使用ROLLBACK​回滚事务。
• 隐式事务控制：如果启用了自动提交模式（autocommit=1​），那么每个SQL语句都会被当作一个独立的事务，执行后立即提交。

‍

1.3.7 事务回滚与恢复

在 MySQL 中，事务回滚会撤销所有未提交的事务修改。数据库会将事务的修改操作记录到 undo log，在回滚时，通过 undo log 撤销已执行的操作。

• 事务恢复： MySQL 使用 redo log 和 undo log 来实现事务的持久化和一致性。当数据库发生崩溃时，系统会根据 redo log 进行恢复，从崩溃前的最后一个提交点重新执行事务，以保证数据一致性。

‍

Savepoint（保存点）

MySQL 事务允许设置保存点（Savepoint），这是一个在事务中设置的检查点。事务可以在保存点处回滚，而不是回滚整个事务。这有助于在事务执行过程中进行部分撤销。

• 创建保存点： SAVEPOINT savepoint_name;
• 回滚到保存点： ROLLBACK TO SAVEPOINT savepoint_name;
• 释放保存点： RELEASE SAVEPOINT savepoint_name;

‍

1.3.8 并发控制与死锁检测

MySQL 使用锁和事务隔离级别来处理并发事务时的数据访问问题。在多事务并发的情况下，可能会发生 死锁（deadlock），即两个或多个事务相互等待对方释放锁，导致所有事务都无法继续执行。

• MySQL 会自动检测死锁，并回滚其中一个事务，解除死锁情况。
• 死锁检测机制：MySQL 定期检查事务之间的锁等待情况，一旦发现死锁，会自动选择一个事务回滚，从而释放锁资源。

‍

1.3.9 InnoDB 存储引擎与事务

InnoDB 存储引擎是 MySQL 默认的事务存储引擎，支持 ACID 属性并通过行级锁和多版本并发控制（MVCC）来提高事务的隔离性。InnoDB 存储引擎的特点包括：

• 支持事务（ACID）。
• 使用行级锁。
• 支持外键约束。
• 支持自动提交和显式提交。

‍

‍

二、Mysql事务使用

2.1 事务的基本操作

在 MySQL 中，通常通过以下 SQL 语句来管理事务：

• START TRANSACTION 或 BEGIN: 开始一个新的事务。
• COMMIT: 提交当前事务，保存所有在事务期间的更改。
• ROLLBACK: 撤销当前事务，回滚到事务开始前的状态。

‍

MySQL 提供了几种 SQL 语句来控制事务的执行：

• 开始事务： 使用 START TRANSACTION​ 或 BEGIN​ 来显式地开始一个事务。 START TRANSACTION; -- 或者 BEGIN;
• 提交事务： 使用 COMMIT​ 来提交事务，将事务中的所有操作持久化到数据库中。 COMMIT;
• 回滚事务： 使用 ROLLBACK​ 来回滚事务，撤销事务中的所有操作，数据恢复到事务开始前的状态。 ROLLBACK;
• 设置保存点：SAVEPOINT​ 允许在事务中设置保存点，可以在某个特定位置回滚到这个保存点。 SAVEPOINT savepoint_name;
• 回滚到保存点： 使用 ROLLBACK TO SAVEPOINT​ 回滚到某个保存点，而不是回滚整个事务。 ROLLBACK TO SAVEPOINT savepoint_name;
• 释放保存点： 使用 RELEASE SAVEPOINT​ 释放保存点。 RELEASE SAVEPOINT savepoint_name;

‍

‍

2.2 事务的使用示例

这里完整地展示 MySQL 中的事务操作，演示如何在银行转账场景下使用这些操作。首先初始化相关数据：包括在 accounts​ 表中插入账户余额数据，以及在 transactions​ 表中插入一些初始的交易记录。这样能够确保转账操作有实际数据支持。

以下是完整的 SQL 示例，包括账户数据的初始化、转账操作的执行、以及在不同情形下使用事务（提交、回滚等）的操作。

‍

1. 数据库表的创建

首先，我们创建 accounts​ 和 transactions​ 两个表，accounts​ 表用来存储账户信息，transactions​ 表用来存储交易记录。

-- 创建 accounts 表
CREATE TABLE accounts (
    account_id INT PRIMARY KEY,
    balance DECIMAL(10, 2) -- 账户余额
);
​
-- 创建 transactions 表
CREATE TABLE transactions (
    transaction_id INT AUTO_INCREMENT PRIMARY KEY,
    account_id INT,
    amount DECIMAL(10, 2),
    transaction_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    FOREIGN KEY (account_id) REFERENCES accounts(account_id)
);

image

​

‍

image

​

‍

image

​

‍

2. 插入初始账户数据

接着，我们插入一些初始的账户数据，为转账操作提供支持。

-- 插入账户数据
INSERT INTO accounts (account_id, balance) VALUES (1, 500.00);  -- 账户 A，余额 500
INSERT INTO accounts (account_id, balance) VALUES (2, 300.00);  -- 账户 B，余额 300

image

​

‍

image

​

‍

3. 完整的转账事务（成功的案例）

假设我们要从账户 A 向账户 B 转账 100 元。以下是一个成功的转账操作流程：

-- 开始事务
START TRANSACTION;
​
-- 从账户 A 提款 100
UPDATE accounts SET balance = balance - 100 WHERE account_id = 1;
​
-- 向账户 B 存款 100
UPDATE accounts SET balance = balance + 100 WHERE account_id = 2;
​
-- 记录这笔交易：账户 A 提款
INSERT INTO transactions (account_id, amount) VALUES (1, -100);
​
-- 记录这笔交易：账户 B 存款
INSERT INTO transactions (account_id, amount) VALUES (2, 100);
​
-- 提交事务，确保所有操作成功
COMMIT;

‍

image

​

‍

image

​

‍

‍

4. 转账事务（失败的回滚）

如果在某个步骤中发生了错误（比如账户 B 不存在），我们希望回滚所有操作，确保数据库状态不会被部分修改。以下是模拟账户 B 不存在的情况。

-- 开始事务
START TRANSACTION;
​
-- 从账户 A 提款 100
UPDATE accounts SET balance = balance - 100 WHERE account_id = 1;
​
-- 假设账户 B 不存在，更新失败
UPDATE accounts SET balance = balance + 100 WHERE account_id = 999;  -- 假设账户 999 不存在
​
-- 如果有错误，回滚所有操作
ROLLBACK;

在上面的例子中，由于账户 B（ID 为 999）不存在，第二条 UPDATE​ 语句将不会更新任何数据。事务会执行回滚操作，恢复事务开始前的数据状态，避免账户 A 的余额被错误地扣除。

‍

image

​

‍

image

​

‍

image

​

‍

image

​

‍

image

​

‍

image

​

‍

5. 使用 Savepoint（保存点）回滚部分操作

如果我们想在一个事务中只回滚部分操作，而不是全部操作，可以使用保存点（Savepoint）。保存点允许你在事务的过程中设置检查点，然后根据需要回滚到某个特定的保存点。

-- 开始事务
START TRANSACTION;
​
-- 设置保存点：记录账户 A 更新之前的状态
SAVEPOINT before_account_a_update;
​
-- 从账户 A 提款 100
UPDATE accounts SET balance = balance - 100 WHERE account_id = 1;
​
-- 设置另一个保存点：记录账户 B 更新之前的状态
SAVEPOINT before_account_b_update;
​
-- 向账户 B 存款 100
UPDATE accounts SET balance = balance + 100 WHERE account_id = 2;
​
-- 假设发生了错误，回滚到账户 A 更新前的状态
ROLLBACK TO SAVEPOINT before_account_a_update;
​
-- 提交事务
COMMIT;

在这个示例中：

• 当执行到 UPDATE accounts SET balance = balance - 100 WHERE account_id = 1;​ 时，系统会设置一个保存点 before_account_a_update​。
• 然后我们继续执行账户 B 的存款操作，设置另一个保存点 before_account_b_update​。
• 如果发生了错误或需要撤销操作，我们可以使用 ROLLBACK TO SAVEPOINT​ 回滚到某个保存点。在这个例子中，我们回滚到 before_account_a_update​，撤销对账户 A 的修改，但不会撤销账户 B 的存款操作。

‍

6. 设置事务的隔离级别

MySQL 支持不同的事务隔离级别，以控制事务之间的并发行为。以下是如何设置事务的隔离级别：

-- 设置事务的隔离级别为 READ COMMITTED
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
​
-- 开始事务
START TRANSACTION;
​
-- 执行操作
UPDATE accounts SET balance = balance - 50 WHERE account_id = 1;
​
-- 提交事务
COMMIT;

常见的事务隔离级别：

1. READ UNCOMMITTED：允许读取未提交的数据，可能导致脏读（Dirty Reads）。
2. READ COMMITTED：只能读取已提交的数据，避免脏读，但仍可能会发生不可重复读（Non-repeatable Reads）。
3. REPEATABLE READ：确保在同一事务中多次查询结果一致，避免脏读和不可重复读（MySQL 默认的隔离级别）。
4. SERIALIZABLE：最严格的隔离级别，通过强制锁定整个数据集来防止并发事务，避免所有事务问题，但性能最差。

‍

总结

通过以上步骤，我们演示了如何在 MySQL 中使用事务进行银行转账操作。关键的步骤包括：

• START TRANSACTION：开始事务。
• COMMIT：提交事务，保存所有操作。
• ROLLBACK：回滚事务，撤销所有操作。
• SAVEPOINT：在事务中设置保存点，允许部分回滚。
• 事务隔离级别：控制事务之间的并发行为，防止脏读、不可重复读等问题。

通过这些功能，MySQL 提供了强大的事务支持，确保数据库在并发访问和多步骤操作中的一致性和可靠性。

‍

在实际开发中，往往使用框架提供的事务支持，简化在应用中管理数据库事务的复杂性。后续将深入分析Java Spring框架，手撕源码，看Spring创始人，音乐学博士学位获得者，Rod Johnson，二十多年前通过精妙的设计，巧妙地实现了事务管理机制。这种设计不仅体现了深厚的技术功底，也让人感叹科学的尽头也许就是哲学，艺术。

‍

创作不易，如果您喜欢这篇文章，记得点赞并关注，后续将会有更多内容与深入分析

1706858207711