MySQL基础篇之 6. 事务

MySQL基础篇之 6. 事务

6.1 事务简介

事务是指一组操作的集合，它是一个不可分割的工作单位。事务会把所有的操作作为一个整体，一起提交或者撤销，确保这些操作要么全部成功，要么全部失败。事务的概念确保了在执行多个数据库操作时，数据的一致性和可靠性。例如，在转账操作中，张三给李四转账1000元，操作必须是一个事务，要么张三的账户减少1000元，李四的账户增加1000元，要么两个操作都失败，从而保证数据的一致性。

• 正常情况：在一个事务中执行转账操作，确保资金转移前后账户的平衡。

• 异常情况：如果某个步骤失败（如在转账过程中发生错误），事务会回滚，确保账户数据的恢复，避免数据不一致。

6.2 事务操作

6.2.1 未控制事务

1). 测试正常情况：在正常情况下，数据操作前后会保持一致，操作成功后账户余额正确。

2). 测试异常情况：在操作过程中，出现错误（如SQL语法错误），会导致部分操作成功，而另一些操作失败，从而导致数据不一致。

drop table if exists account;
create table account(
    id int primary key AUTO_INCREMENT comment 'ID',
    name varchar(10) comment '姓名',
    money double(10,2) comment '余额'
) comment '账户表';

insert into account(name, money) VALUES ('张三',2000), ('李四',2000);

-- 执行转账操作
-- 1. 查询张三余额
select * from account where name = '张三';

-- 2. 张三的余额减少1000
update account set money = money - 1000 where name = '张三';

-- 3. 李四的余额增加1000
update account set money = money + 1000 where name = '李四';

在执行过程中如果遇到错误（如第二步出错），导致数据不一致。此时需要手动回滚数据。

6.2.2 控制事务

在MySQL中，可以通过控制事务的提交方式来手动管理事务：

1). 查看/设置事务提交方式：

SELECT @@autocommit; -- 查看自动提交模式
SET @@autocommit = 0; -- 禁用自动提交

2). 提交事务：一旦操作成功，使用 commit 提交事务。

COMMIT;

3). 回滚事务：如果在执行过程中遇到错误，使用 rollback 回滚事务，恢复到事务开始时的状态。

ROLLBACK;

6.2.3 控制事务 - 示例

-- 开启事务
START TRANSACTION;

-- 执行转账操作
UPDATE account SET money = money - 1000 WHERE name = '张三';
UPDATE account SET money = money + 1000 WHERE name = '李四';

-- 如果操作成功，提交事务
COMMIT;

-- 如果出现错误，回滚事务
-- ROLLBACK;

6.3 事务四大特性

事务的四大特性（ACID）是保证数据库操作可靠性的核心：

1). 原子性（Atomicity）：事务是不可分割的最小操作单元，要么全部成功，要么全部失败。
2). 一致性（Consistency）：事务完成时，数据库必须保持一致的状态，任何中途的错误都会导致数据不一致。
3). 隔离性（Isolation）：事务执行时，其他事务不能看到它的中间状态，确保每个事务独立执行。
4). 持久性（Durability）：一旦事务提交，对数据库的修改是永久性的，即使系统崩溃也不会丢失。

6.4 并发事务问题

并发事务中可能会遇到以下问题：

1). 脏读：事务A读到了事务B未提交的数据。
2). 不可重复读：事务A两次读取同一条记录，但数据发生了变化。
3). 幻读：事务A在读取数据时，没有读取到某些记录，但后续的插入操作使得这些记录存在，导致数据出现"幻影"。

6.5 事务隔离级别

为了避免并发事务引发的问题，数据库提供了不同的事务隔离级别。常见的隔离级别如下：

• Read Uncommitted：允许脏读，不可重复读，幻读。

• Read Committed：禁止脏读，允许不可重复读，幻读。

• Repeatable Read：禁止脏读和不可重复读，允许幻读（MySQL的默认隔离级别）。

• Serializable：禁止脏读、不可重复读和幻读，提供最高的数据隔离性。

-- 查看当前事务隔离级别
SELECT @@TRANSACTION_ISOLATION;

-- 设置事务隔离级别
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;

在事务处理时，隔离级别越高，数据越安全，但性能可能会受到影响，因此需要根据业务需求进行调整。

---

理论理解

事务是数据库管理系统（DBMS）中的一个重要概念，它是由一组操作组成的不可分割的工作单位。事务的关键特点是：要么所有操作都成功（提交事务），要么所有操作都失败（回滚事务）。这一设计确保了数据在操作过程中始终保持一致性和完整性，特别是在面临并发操作和系统故障时。事务保证了数据库的一致性、可靠性、稳定性和准确性。

事务操作通常有以下几个要素：

1. ACID特性：事务必须满足四个特性，即原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durability）。这些特性共同保证了在执行事务时，数据不会遭到破坏或不一致，且在事务提交后，数据变更是持久的，不会丢失。

   • 原子性确保事务内的操作要么全成功，要么全失败。

   • 一致性保证事务执行后数据库从一个一致性状态转变为另一个一致性状态。

   • 隔离性确保事务执行时的中间状态不被其他事务访问，避免并发操作造成的冲突。

   • 持久性保证事务一旦提交，其对数据的更改将持久化，即使系统发生崩溃也不会丢失。

2. 事务的控制：在MySQL中，事务的默认行为是自动提交（即每执行一个SQL语句都会立即提交）。通过手动控制事务（使用START TRANSACTION、COMMIT、ROLLBACK等语句），可以确保在多个操作步骤中，只有在所有步骤成功时，事务才会提交，从而保证数据的一致性。

   • 在正常操作过程中，事务保证了如转账这样的多步骤操作的原子性：即所有操作必须在一个事务中成功执行。

   • 如果事务执行中出现任何错误，事务将通过回滚机制恢复数据的原始状态，避免部分操作成功而其他操作失败导致的数据不一致。

3. 并发事务问题：当多个事务同时执行时，可能会遇到并发事务的各种问题，如脏读、不可重复读和幻读等。

   • 脏读：一个事务读取到了另一个事务尚未提交的数据，可能导致错误的读取结果。

   • 不可重复读：同一个事务多次读取同一数据，数据却发生了变化，导致结果不一致。

   • 幻读：在事务执行期间，满足查询条件的数据发生了变化，导致查询结果与期望不符。

为了解决这些问题，数据库提供了不同的事务隔离级别，分别是Read Uncommitted、Read Committed、Repeatable Read（MySQL默认隔离级别）和Serializable。每种隔离级别对并发事务的处理方式不同，影响数据的一致性和性能。

大厂实战理解

在大厂的实际业务中，事务的应用无处不在，尤其在分布式系统、高并发系统和金融、电商等领域，事务的管理尤为关键。

1. 金融交易系统：在银行转账、支付结算等金融场景中，事务控制是不可或缺的。例如，支付宝、微信支付等系统会使用事务确保一系列操作的原子性，确保账户余额正确、支付记录准确，避免资金丢失或错误转账。

2. 电商平台：在电商平台上，订单的创建、支付、库存扣减等操作通常需要事务支持。例如，用户购买商品时，系统需要在多个数据库表之间进行一致的操作（如订单表、商品库存表等），确保库存和订单的准确性。若某一操作失败，整个事务会回滚，防止数据不一致。

3. 分布式事务：在微服务架构或分布式系统中，事务的管理更为复杂。传统的单机事务可以通过COMMIT和ROLLBACK轻松控制，但在分布式系统中，跨服务、跨数据库的事务管理面临挑战。大厂通常使用两阶段提交（2PC）、三阶段提交（3PC）等协议来保证分布式事务的一致性。此外，TCC（Try-Confirm-Cancel）模式和Saga模式也被广泛应用于解决分布式事务的可靠性问题。

4. 隔离级别的选择与性能权衡：在实际项目中，开发人员根据业务需求选择合适的事务隔离级别。例如，在电商系统中，Repeatable Read通常是默认隔离级别，以确保商品库存的准确性和订单的一致性。然而，在高并发场景下，为了提高性能，可能会使用Read Committed，在保证一定程度的数据一致性的同时提高系统吞吐量。大厂往往通过合理设置事务隔离级别与优化并发控制，平衡数据一致性与系统性能。

结论

事务是数据库管理中至关重要的概念，其通过ACID特性保障了数据的完整性和一致性。在实际应用中，事务不仅保证了基本的数据库操作正确性，也在高并发、分布式系统中扮演着不可或缺的角色。合理使用事务控制和选择合适的事务隔离级别，是大厂开发过程中优化数据一致性和性能的关键。

 

MySQL基础篇之 6. 事务 - 大厂面试题

面试题 1: 事务的ACID特性是什么？它们在实际应用中的意义是什么？

参考答案：
ACID特性是事务的四个基本特性，分别是：

1. 原子性（Atomicity）：事务中的所有操作要么全部成功，要么全部失败。原子性保证了事务是不可分割的，要么所有操作都完成，要么事务完全不执行。这在保证数据一致性方面至关重要。例如，在银行转账操作中，确保转账的扣款和存款两部分要么都成功，要么都不执行。

2. 一致性（Consistency）：事务的执行必须将数据库从一个一致的状态转变为另一个一致的状态。数据库在事务执行前后必须保持一致性。例如，在订单处理系统中，只有当订单创建和支付等操作都成功时，才算订单有效。

3. 隔离性（Isolation）：事务的执行不受其他事务的影响。不同事务之间的执行是相互独立的。即使多个事务并发执行，它们的中间状态不能被其他事务看到。隔离性防止了并发执行时可能出现的数据问题，如脏读、不可重复读和幻读。

4. 持久性（Durability）：一旦事务提交，事务对数据库的修改就会永久生效，即使系统崩溃也不会丢失。持久性确保了事务提交后的数据不会丢失，保障了数据的可靠性。

在实际应用中，这四个特性能够确保数据库在复杂的事务操作下保持一致性和可靠性，尤其在银行、支付、电商等行业非常重要。

---

面试题 2: 在MySQL中，如何控制事务的提交与回滚？举一个实际应用的例子。

参考答案：
在MySQL中，可以通过以下方式手动控制事务的提交与回滚：

1. 开启事务：使用 START TRANSACTION 或 BEGIN 命令开始一个事务。

2. 提交事务：使用 COMMIT 命令提交事务，表示事务中的所有操作将永久写入数据库。

3. 回滚事务：使用 ROLLBACK 命令回滚事务，表示事务中的所有操作都将被撤销，数据库恢复到事务开始时的状态。

实际应用例子：
假设在一个电商平台中，用户进行支付操作时，需要同时更新订单状态和减少库存量。为了确保操作的原子性，必须将这些操作放入同一个事务中。若在操作过程中出现错误，必须回滚所有操作，避免部分操作成功导致数据不一致。

START TRANSACTION;

-- 执行更新订单状态
UPDATE orders SET status = 'paid' WHERE order_id = 123;

-- 执行减少库存
UPDATE products SET stock = stock - 1 WHERE product_id = 456;

-- 如果没有错误，则提交事务
COMMIT;

-- 如果发生错误，回滚事务
-- ROLLBACK;

---

面试题 3: 什么是事务隔离级别？MySQL中有哪些事务隔离级别？它们的区别是什么？

参考答案：
事务隔离级别是指在并发执行事务时，数据库为保证事务之间的隔离性所采取的策略。MySQL支持以下几种事务隔离级别：

1. Read Uncommitted：允许脏读，即一个事务可以读取另一个事务未提交的数据。此级别提供最低的隔离性和最低的性能开销。

2. Read Committed：禁止脏读，但允许不可重复读。即一个事务只能读取已经提交的数据，但如果另一个事务修改了数据，该事务会读取到修改后的数据。

3. Repeatable Read（MySQL默认级别）：禁止脏读和不可重复读，但允许幻读。即事务在开始后，读取的数据在整个事务期间保持一致（数据不会改变），但可能会插入新的行满足查询条件。

4. Serializable：提供最高的隔离级别，禁止脏读、不可重复读和幻读。此级别通过强制事务排队执行，确保每个事务在独立的隔离环境中执行。

区别：

• Read Uncommitted：最低的隔离级别，允许脏读，数据一致性差，适用于对数据一致性要求不高的场景。

• Read Committed：较高的隔离级别，避免脏读，适用于要求较高的数据一致性，但容忍不可重复读。

• Repeatable Read：MySQL的默认级别，能够解决脏读和不可重复读，但仍然可能发生幻读。适用于大多数OLTP（在线事务处理）应用。

• Serializable：最高的隔离级别，避免脏读、不可重复读和幻读，但性能较低，适用于需要严格隔离的场景。

---

面试题 4: 什么是脏读、不可重复读和幻读？如何通过事务隔离级别解决这些问题？

参考答案：

1. 脏读（Dirty Read）：一个事务读取到另一个事务尚未提交的数据。这些数据可能会在后续的回滚操作中丢失，导致读取的数据不可靠。

   • 解决方法：使用 Read Committed 或更高级别的隔离级别，避免脏读。

2. 不可重复读（Non-repeatable Read）：在同一事务中，对同一数据进行多次读取，但读取到的数据不同。即其他事务在事务A读取数据后修改了数据，导致事务A读取到不同的值。

   • 解决方法：使用 Repeatable Read 隔离级别，保证事务期间的读取结果一致。

3. 幻读（Phantom Read）：一个事务在读取某些数据时，结果集没有匹配任何记录，但在该事务执行期间，其他事务插入了符合查询条件的新数据，导致查询结果发生变化。

   • 解决方法：使用 Serializable 隔离级别，通过强制事务串行化执行，避免幻读。

---

面试题 5: 请解释如何通过MySQL事务来实现银行转账操作，确保资金转账的一致性。

参考答案：
在银行转账操作中，我们需要确保资金转账的原子性和一致性。即使在出现故障或错误时，也要确保转账操作要么完全成功，要么完全失败，不会导致资金不一致。

在MySQL中，我们可以通过事务来实现这一点：

1. 开启事务。

2. 从张三账户扣除1000元。

3. 向李四账户增加1000元。

4. 如果操作成功，提交事务。

5. 如果操作过程中出现错误（例如，张三账户余额不足），则回滚事务。

示例SQL：

START TRANSACTION;

-- 执行从张三账户扣款
UPDATE account SET money = money - 1000 WHERE name = '张三';

-- 执行向李四账户加款
UPDATE account SET money = money + 1000 WHERE name = '李四';

-- 如果没有错误，则提交事务
COMMIT;

-- 如果出现错误，回滚事务
-- ROLLBACK;

通过事务控制，确保整个转账过程在一个事务中完成，避免部分操作成功而导致数据不一致的情况。如果在操作过程中发生任何错误，系统会回滚事务，恢复到事务开始时的状态，从而保证资金的一致性。

 

MySQL基础篇之 6. 事务 - 大厂场景题

场景题 1: 在一个电商平台中，用户购买商品时涉及到库存扣减、订单创建和支付等多个操作，如何使用事务确保数据一致性？

参考答案：
在电商平台中，用户购买商品时需要进行多个操作，例如：库存扣减、订单创建和支付处理。这些操作必须确保原子性，即要么所有操作成功，要么所有操作失败，避免出现库存扣减成功但订单未创建或支付未成功的情况。

为确保数据一致性，可以通过事务控制这些操作：

1. 开启事务。

2. 扣减商品库存。

3. 创建订单。

4. 处理支付。

5. 如果所有操作成功，提交事务；如果出现错误，回滚事务。

START TRANSACTION;

-- 扣减库存
UPDATE products SET stock = stock - 1 WHERE product_id = 123 AND stock > 0;

-- 创建订单
INSERT INTO orders (user_id, product_id, amount, status) VALUES (456, 123, 1, 'pending');

-- 处理支付
INSERT INTO payments (order_id, payment_amount, status) VALUES (LAST_INSERT_ID(), 100.00, 'success');

-- 如果操作成功，提交事务
COMMIT;

-- 如果发生错误，回滚事务
-- ROLLBACK;

在此过程中，如果任何操作失败，ROLLBACK 会撤销所有操作，确保数据一致性。

---

场景题 2: 在银行系统中，两个用户之间的转账操作需要确保资金一致性和原子性，如何设计事务来确保这一点？

参考答案：
在银行系统中，用户之间的转账操作需要确保资金的一致性。假设用户A转账给用户B，转账过程中必须保证资金的原子性：要么两笔操作（从A账户扣款、向B账户加款）都成功，要么两笔操作都失败。

为了确保一致性，可以使用事务来保证：

1. 开启事务。

2. 从用户A的账户中扣除转账金额。

3. 向用户B的账户中添加转账金额。

4. 如果所有操作成功，提交事务；如果出错，回滚事务。

START TRANSACTION;

-- 扣除用户A的转账金额
UPDATE accounts SET balance = balance - 1000 WHERE user_id = 1 AND balance >= 1000;

-- 向用户B的账户增加转账金额
UPDATE accounts SET balance = balance + 1000 WHERE user_id = 2;

-- 如果所有操作成功，提交事务
COMMIT;

-- 如果发生错误，回滚事务
-- ROLLBACK;

在这个场景中，使用事务保证了扣款和存款操作的原子性。如果在操作过程中发生任何错误（如用户A余额不足），事务会回滚，确保没有出现部分成功的情况，资金数据的一致性得以保证。

---

场景题 3: 在一个库存管理系统中，如何处理并发情况下的库存更新，确保库存数据的一致性？

参考答案：
在库存管理系统中，处理并发情况下的库存更新是一个常见问题。例如，多个用户同时购买同一商品，如何确保每个用户都能正确扣减库存？

问题：多个事务并发执行时，可能会出现如下问题：

• 脏读：一个事务读取到另一个事务尚未提交的数据。

• 不可重复读：一个事务两次读取同一数据，读取结果不同。

• 幻读：一个事务查询到的数据集不一致。

为了解决并发问题，可以使用事务隔离级别来避免这些问题，尤其是使用Repeatable Read或Serializable级别。

1. 解决方案：采用Repeatable Read事务隔离级别来确保每个事务都看到一致的库存数据。

2. 使用悲观锁：通过在更新库存时加锁，避免多个事务并发修改相同库存。

示例实现：

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;

START TRANSACTION;

-- 通过悲观锁，防止其他事务修改库存
SELECT * FROM products WHERE product_id = 123 FOR UPDATE;

-- 更新库存
UPDATE products SET stock = stock - 1 WHERE product_id = 123 AND stock > 0;

-- 提交事务
COMMIT;

-- 如果库存不足，回滚事务
-- ROLLBACK;

在此场景中，FOR UPDATE 用于加锁，确保在库存更新时其他事务无法同时修改同一数据，避免并发问题，从而保证库存数据的一致性。

---

场景题 4: 在一个多线程并发访问的库存系统中，如何处理库存不足的情况，避免出现超卖？

参考答案：
在库存系统中，多个并发请求可能同时尝试购买相同商品，如果没有正确的同步机制，可能会出现超卖现象。为了避免这种情况，可以通过事务和锁机制来控制并发，确保在库存不足时不会超卖。

方案：通过FOR UPDATE锁定库存行，确保在库存扣减时其他事务无法同时操作库存，从而避免超卖。

1. 开启事务。

2. 查询库存并加锁。

3. 扣减库存，如果库存不足，回滚事务。

4. 提交事务。

START TRANSACTION;

-- 查询并加锁库存
SELECT stock FROM products WHERE product_id = 123 FOR UPDATE;

-- 如果库存足够，进行扣减
UPDATE products SET stock = stock - 1 WHERE product_id = 123 AND stock > 0;

-- 如果库存不足，回滚事务
-- 若库存小于0，回滚
-- ROLLBACK;

-- 提交事务
COMMIT;

通过加锁和事务控制，确保了库存操作的原子性和一致性。如果库存不足，事务会回滚，避免出现库存超卖的问题。

---

场景题 5: 如何在一个系统中处理跨数据库事务，确保数据一致性和可靠性？

参考答案：
在跨数据库事务中，操作涉及多个数据库，通常需要保证跨数据库的数据一致性。这种场景常常在分布式系统中出现。传统的数据库事务无法直接支持跨数据库的操作，因此通常使用分布式事务来确保跨多个数据库的数据一致性。

解决方案：采用两阶段提交（2PC）协议或Saga模式来处理跨数据库事务。

1. 两阶段提交（2PC）：

   • 第一阶段：所有参与的数据库事务准备提交，并通知协调者。

   • 第二阶段：如果所有数据库都准备好，协调者提交事务；如果任何数据库没有准备好，协调者回滚所有数据库的事务。

2. Saga模式：将跨数据库事务拆分为多个子事务，每个子事务独立提交。如果任何子事务失败，执行补偿操作回滚之前的事务。

示例：在一个分布式订单管理系统中，订单数据保存在MySQL数据库中，支付数据保存在另一个PostgreSQL数据库中。使用分布式事务保证两个数据库的数据一致性。

-- 假设使用分布式事务协议，例如TCC或2PC进行跨数据库操作
-- 提交MySQL的订单数据事务
START TRANSACTION;  -- MySQL
UPDATE orders SET status = 'paid' WHERE order_id = 123;
COMMIT;  -- MySQL

-- 提交PostgreSQL的支付数据事务
START TRANSACTION;  -- PostgreSQL
INSERT INTO payments (order_id, payment_amount) VALUES (123, 100.00);
COMMIT;  -- PostgreSQL

在这种情况下，使用分布式事务协议确保跨数据库的操作要么全部成功，要么全部失败，避免出现部分提交的情况。