MySQL事务隔离级别
目录
事务
一 事务的四大特性（ACID）
1 原子性(Atomicity) ：
2 一致性(Consistent)
3 隔离性（Isolation）
4 持久性（Durability）
二 事务的生命周期
三 并发事务带来的问题
四 事务的隔离级别
MySQL 可重复读的特殊性
五 事务的实现原理
1. Redo Log（重做日志）
2. Undo Log（回滚日志）
3. MVCC（多版本并发控制）
六 事务最佳实践
七 事务选择决策
事务
事务是数据库管理系统执行过程中的一个逻辑工作单元，它由一系列数据库操作组成，这些操作要么全部成功，要么全部失败（不会出现部分成功、部分失败的情况）。
一 事务的四大特性（ACID）
1 原子性(Atomicity) ：
定义：事务中的所有操作是一个不可分割的整体，要么全部执行成功，要么全部不执行（回滚）。
实现原理：
Undo Log（回滚日志）：记录数据修改前的旧值
事务失败时，通过 Undo Log 将数据恢复到事务开始前的状态
2 一致性(Consistent)
定义：事务执行前后，数据库从一个一致状态转变为另一个一致状态，完整性约束不被破坏。
注意：一致性是 ACID 的最终目标，原子性、隔离性、持久性都是为了实现一致性。
3 隔离性（Isolation）
定义：多个事务并发执行时，相互隔离，互不干扰。
实现原理：
锁机制：共享锁、排他锁
MVCC（多版本并发控制）：通过数据版本链实现读写不互斥
隔离级别（从低到高）：
读未提交：可能脏读
读已提交：避免脏读
可重复读：避免脏读、不可重复读（MySQL默认）
串行化：避免所有并发问题
4 持久性（Durability）
定义：事务一旦提交，对数据的修改就是永久性的，即使系统崩溃也不会丢失。
实现原理：
Redo Log（重做日志）：记录数据修改后的新值
事务提交时，先将 Redo Log 写入磁盘
系统恢复时，通过 Redo Log 重放已提交的事务
两阶段提交：
事务执行 → 写入 Redo Log（prepare状态）→ 写入binlog →提交 → Redo Log 变为 commit 状态 → 数据写入磁盘（空闲时）
二 事务的生命周期
-- 1. 开始事务
START TRANSACTION; -- 或 BEGIN;
-- 2. 执行 SQL 操作
INSERT INTO user(name) VALUES('张三');
UPDATE account SET balance = 1000 WHERE id = 1;
-- 3. 提交事务（永久生效）
COMMIT;
-- 或回滚事务（撤销所有操作）
ROLLBACK;
三 并发事务带来的问题
| 问题 | 描述 | 示例 |
|---|---|---|
| 脏读 | 读到其他事务未提交的数据 | 事务A读到事务B未提交的修改，B回滚，A读到脏数据 |
| 不可重复读 | 同一事务内两次读同一数据结果不同，不符合隔离性 | 事务A两次读取余额，中间事务B修改并提交，两次结果不一致 |
| 幻读 | 同一事务内两次范围查询结果集行数不同，不符合隔离性 | 事务A两次查询用户列表，中间事务B插入新用户，两次结果条数不同 |
| 丢失更新 | 后提交的更新覆盖了先提交的更新 | 两人同时编辑同一数据，后保存者覆盖先保存者的修改 |
四 事务的隔离级别
| 隔离级别 | 脏读 | 不可重复读 | 幻读 | 并发性能 | 默认数据库 |
|---|---|---|---|---|---|
| 读未提交 | ❌ 可能 | ❌ 可能 | ❌ 可能 | 最高 | - |
| 读已提交 | ✅避免 | ❌ 可能 | ❌ 可能 | 高 | Oracle, SQL Server |
| 可重复读 | ✅ 避免 | ✅ 避免 | ⚠️ InnoDB解决 | 中 | MySQL |
| 串行化 | ✅ 避免 | ✅ 避免 | ✅ 避免 | 最低 | - |
MySQL 可重复读的特殊性
MySQL InnoDB 通过以下机制，在可重复读级别解决了幻读：
MVCC（多版本并发控制）：事务在第一次读取时生成快照（Read View），后续所有读取都基于这个快照。
间隙锁（Gap Lock）：在范围查询时锁定索引记录之间的间隙，防止幻影行插入。
五 事务的实现原理
1. Redo Log（重做日志）
作用：保证持久性
机制：
记录数据修改后的新值
采用 WAL（Write-Ahead Logging）技术：先写日志，后写磁盘
循环写入（固定大小），写满后会触发 checkpoint
2. Undo Log（回滚日志）
作用：保证原子性和 MVCC
机制：
记录数据修改前的旧值
用于事务回滚和数据版本管理
形成版本链，支持 MVCC 快照读
3. MVCC（多版本并发控制）
核心思想：读写不互斥，写操作创建新版本，读操作读取旧版本
关键组件：
隐藏字段：DB_TRX_ID（事务ID）、DB_ROLL_PTR（回滚指针）
Read View（一致性视图）：记录当前活跃事务列表
Undo Log 版本链：按时间顺序存储的历史版本
读操作分类：
快照读：普通
SELECT，读取历史版本，无锁当前读：
SELECT ... FOR UPDATE、UPDATE、DELETE，读取最新版本，加锁
六 事务最佳实践
| 实践 | 说明 | 示例 |
|---|---|---|
| 事务粒度最小化 | 只在必要范围内使用事务 | 将网络请求、文件操作移出事务 |
| 只读事务优化 | 纯查询使用readOnly=true | @Transactional(readOnly = true) |
| 明确回滚规则 | 指定需要回滚的异常类型 | @Transactional(rollbackFor = Exception.class) |
| 合理的隔离级别 | 根据业务选择，避免盲目使用串行化 | 默认可重复读即可满足多数场景 |
| 处理事务失效 | 注意 self-invocation、public方法等 | 通过代理调用或注入自身 |
| 监控长事务 | 避免事务持有时间过长 | 设置超时时间timeout = 30 |
七 事务选择决策
| 场景 | 推荐方案 | 隔离级别 | 锁策略 |
|---|---|---|---|
| 简单增删改 | 默认事务 | 可重复读 | 默认行锁 |
| 复杂报表查询 | 只读事务 | 可重复读 | 无锁（快照读） |
| 高并发扣库存 | 乐观锁 | 读已提交 | 版本号机制 |
| 热点账户转账 | 悲观锁 | 读已提交 | SELECT FOR UPDATE |
| 数据一致性要求极高 | 串行化 | 串行化 | 表锁/间隙锁 |
| 分布式事务 | 最终一致性 | 读已提交 | TCC/消息表 |
事务是保证数据一致性的核心机制，但需要谨慎使用：事务范围太小可能无法保证一致性，太大则会影响性能。在实际开发中，需要在数据一致性和系统性能之间找到平衡点。