什么是事务，事务有哪几种特性

1. 什么是事务（Transaction）

事务是一组要么全部成功、要么全部失败回滚的数据库操作序列，它的核心价值是：在并发与故障存在的现实环境下，仍能把业务操作当成一个“可靠的原子单元”来完成。

从使用方式上看，事务需要明确“边界”：

• 自动提交（autocommit）：每条 SQL 语句默认就是一个事务。
• 显式事务：由业务显式开启/提交/回滚，覆盖多条 SQL。

START TRANSACTION;
UPDATE account SET balance = balance - 100 WHERE id = 1;
UPDATE account SET balance = balance + 100 WHERE id = 2;
COMMIT;

2. ACID：四个字母分别解决什么问题

ACID 不是口号，最好能说清楚每个字母的“工程含义”。

2.1 原子性（Atomicity）

原子性保证：事务中的操作要么全部提交生效，要么全部回滚，不会出现“扣款成功但加款失败”的中间态。

以 InnoDB 为例，原子性通常依赖：

• Undo Log（回滚日志）：记录修改前的版本，用于回滚与 MVCC。

2.2 一致性（Consistency）

一致性强调：事务执行前后，数据库必须从一个满足约束的状态转移到另一个满足约束的状态。

这里的一致性包含两层：

• 数据库层：主键/唯一/外键、NOT NULL、CHECK（不同数据库支持程度不同）等约束。
• 业务层：例如“余额不能为负”“库存不能小于 0”，常由业务代码 + 事务共同保证。

2.3 隔离性（Isolation）

隔离性保证：多个事务并发执行时，彼此的中间过程互不干扰，避免读取到不一致的中间态。

常见并发现象：

• 脏读（Dirty Read）
• 不可重复读（Non-repeatable Read）
• 幻读（Phantom Read）

隔离性的实现手段通常是：

• 锁（Lock）：行锁、间隙锁等，限制并发写/读写。
• MVCC（多版本并发控制）：读读不加锁，通过版本链与快照读提升并发。

2.4 持久性（Durability）

持久性保证：事务一旦提交，结果在系统崩溃后也不会丢失。

以 InnoDB 为例，持久性通常依赖：

• Redo Log（重做日志）：记录“做了什么修改”，用于崩溃恢复重放。
• 刷盘策略（例如何时 fsync）与组提交（Group Commit）会影响性能与持久性强度。

3. InnoDB 视角：ACID 与组件的对应关系

ACID	典型实现要素（以 InnoDB 为例）
A 原子性	Undo Log + 回滚机制
C 一致性	约束 + 事务语义 + 业务逻辑
I 隔离性	锁 + MVCC + 隔离级别
D 持久性	Redo Log + 刷盘策略 + 崩溃恢复