在数据库操作中，事务是保证数据一致性的核心机制。无论是电商下单时的 "扣库存 + 生成订单"，还是银行转账的 "转出 + 转入"，都需要通过事务确保操作的完整性 ------ 要么全部成功，要么全部失败。作为后端开发常用的数据库，MySQL 的事务机制是 Java 开发者必须掌握的基础技能。今天就从基础概念、核心特性、隔离级别到实战用法，全方位解析 MySQL 事务。
一、什么是 MySQL 事务？
事务（Transaction）是数据库中一组不可分割的操作单元。这组操作要么全部执行成功并永久生效，要么在某个操作失败时，所有已执行的操作全部回滚（撤销），恢复到操作前的状态。
举个经典例子：用户在电商平台下单时，系统需要执行两个关键操作：
- 扣减商品库存（UPDATE stock SET num = num - 1 WHERE id = 1）
- 生成订单记录（INSERT INTO orders ...）
如果没有事务，可能出现 "库存已扣但订单未生成"（如第二步报错），或 "订单已生成但库存未扣"（如第一步报错）的情况，导致数据不一致。而事务能保证这两个操作 "同生共死"，避免中间状态。
二、事务的四大特性（ACID）
MySQL 事务能保证数据一致性，核心依赖于 ACID 四大特性，这也是面试高频考点：
- 原子性（Atomicity）
事务中的所有操作是一个 "原子"------ 不可拆分。要么全部执行成功（提交），要么全部失败（回滚），不存在 "部分执行" 的中间状态。
实现原理：依赖 InnoDB 的 undo log（回滚日志）。事务执行时，InnoDB 会记录操作的反向逻辑（如插入记录时记录删除日志，更新记录时记录旧值），当事务需要回滚时，通过 undo log 反向执行操作，恢复数据。
- 一致性（Consistency）
事务执行前后，数据库的完整性约束（如主键唯一、外键关联、字段校验规则）不会被破坏，数据从一个合法状态转换到另一个合法状态。
举例：转账前 A 账户有 1000 元，B 账户有 2000 元，总金额 3000 元；转账后 A 有 800 元，B 有 2200 元，总金额仍为 3000 元，这就是一致性的体现。
- 隔离性（Isolation）
多个事务同时操作数据库时，每个事务的执行不应被其他事务干扰，事务内部的操作和数据对其他事务是隔离的。
隔离性通过 "隔离级别" 控制（下文详细讲解），隔离级别越高，数据一致性越好，但性能可能越低。
- 持久性（Durability）
事务一旦提交（COMMIT），其修改的数据会被永久保存到数据库（即使后续数据库崩溃，重启后数据仍能恢复）。
实现原理：依赖 InnoDB 的 redo log（重做日志）。事务执行时，操作会先写入 redo log（内存 + 磁盘），再更新内存中的数据页；即使提交后数据库崩溃，重启时 InnoDB 会通过 redo log 恢复未写入磁盘的数据，保证已提交的事务不会丢失。
三、事务的隔离级别
当多个事务同时操作同一批数据时，可能出现脏读、不可重复读、幻读等问题。MySQL 通过 "隔离级别" 控制事务间的可见性，解决这些问题。
- 三种常见的数据不一致问题
- 脏读：事务 A 读取到事务 B "未提交" 的修改。
例：事务 B 修改了一条记录但未提交，事务 A 读取到这个修改后，事务 B 因错误回滚，导致事务 A 读取的数据是 "无效的脏数据"。
- 不可重复读：事务 A 多次读取同一数据时，事务 B "已提交" 的修改导致前后读取结果不一致。
例：事务 A 第一次读取余额为 1000 元，事务 B 转账 200 元并提交，事务 A 再次读取余额变为 1200 元，两次结果不同。
- 幻读：事务 A 按条件查询数据时，事务 B"新增 / 删除" 了符合条件的记录，导致事务 A 再次查询时出现 "新数据" 或 "数据消失"。
例：事务 A 查询 "年龄> 18 的用户" 有 10 人，事务 B 新增 1 个年龄 20 的用户并提交，事务 A 再次查询发现变成 11 人，像出现了 "幻觉"。
- MySQL 的四种隔离级别
MySQL 支持四种隔离级别（由低到高），级别越高，数据一致性越好，但并发性能越低。默认隔离级别为可重复读（Repeatable Read）。
|-------------------------|-----|--------|--------|--------------------|
| 隔离级别 | 脏读 | 不可重复读 | 幻读 | 适用场景 |
| 读未提交（Read Uncommitted） | 可能 | 可能 | 可能 | 对一致性要求极低，几乎不用 |
| 读已提交（Read Committed） | 避免 | 可能 | 可能 | 多数互联网场景（如电商） |
| 可重复读（Repeatable Read） | 避免 | 避免 | 避免 * | MySQL 默认，平衡一致性与性能 |
| 串行化（Serializable） | 避免 | 避免 | 避免 | 一致性要求极高（如金融核心） |
注：MySQL 的 "可重复读" 通过 MVCC（多版本并发控制）避免了幻读，这是 InnoDB 引擎的特性，与其他数据库（如 Oracle）不同。
- 如何查看和设置隔离级别？
- 查看当前隔离级别：
TypeScript取消自动换行复制
-- MySQL 8.0+
SELECT @@transaction_isolation;
-- MySQL 5.7及以下
SELECT @@tx_isolation;
- 设置隔离级别（当前会话生效）：
TypeScript取消自动换行复制
SET TRANSACTION ISOLATION LEVEL 隔离级别名称;
-- 例：设置为读已提交
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
- 全局设置（需重启生效，谨慎操作）：
修改 my.cnf 配置文件，添加：
TypeScript取消自动换行复制
transaction-isolation = REPEATABLE-READ
四、事务的基本操作（实战）
在 MySQL 中，事务默认是 "自动提交"（AUTOCOMMIT=1）------ 每条 SQL 执行后立即生效。若要手动控制事务，需先关闭自动提交，再通过 COMMIT 和 ROLLBACK 管理。
基本语法：
TypeScript取消自动换行复制
-- 1. 关闭自动提交（仅当前会话生效）
SET AUTOCOMMIT = 0;
-- 2. 开始事务（可选，关闭自动提交后默认开启）
START TRANSACTION;
-- 3. 执行事务操作（多条SQL）
UPDATE stock SET num = num - 1 WHERE id = 1; -- 扣库存
INSERT INTO orders (user_id, goods_id) VALUES (100, 1); -- 生成订单
-- 4. 若所有操作成功，提交事务（永久生效）
COMMIT;
-- 5. 若操作失败，回滚事务（撤销所有操作）
-- ROLLBACK;
注意事项：
- 若未手动 COMMIT，且会话断开（如客户端关闭），MySQL 会自动 ROLLBACK。
- 部分 SQL 会隐式触发事务提交（如 DDL 语句：CREATE TABLE、ALTER TABLE），即使未手动 COMMIT，执行后也会提交当前事务。
- 在 Java 中，可通过 JDBC 或框架（如 MyBatis、Spring）控制事务，核心逻辑一致：开启事务→执行 SQL→成功提交 / 失败回滚。
五、事务的实现原理（进阶）
理解事务底层原理，能帮你更好地排查问题（如事务死锁、性能瓶颈）。InnoDB 引擎通过以下机制实现事务：
- undo log（回滚日志）：保证原子性
- 作用：记录事务执行前的数据状态，用于事务回滚。
- 过程：执行 UPDATE/INSERT/DELETE 时，InnoDB 会生成对应的 undo log（如 UPDATE 前记录旧值，INSERT 前记录 "删除" 日志）。若事务需要回滚，通过 undo log 反向操作，恢复数据。
- redo log（重做日志）：保证持久性
- 作用：记录事务对数据的修改，确保提交后的数据不丢失（即使数据库崩溃）。
- 过程：事务执行时，修改先写入内存中的 "数据页"，同时将修改记录写入 redo log（先写内存缓冲区，再异步刷到磁盘）。若提交后数据库崩溃，重启时 InnoDB 会通过 redo log 恢复未写入磁盘的数据。
- MVCC（多版本并发控制）：实现隔离性
- 作用：让不同事务在并发读写时 "看到" 不同版本的数据，避免锁竞争。
- 核心：每行数据包含隐藏列（如 row_id、trx_id 事务 ID、roll_ptr 回滚指针），通过 undo log 构建数据的历史版本。事务读取时，根据隔离级别读取对应版本的数据（如可重复读会固定读取事务开始时的版本）。
- 锁机制：辅助隔离性
- 行锁：对单行数据加锁（如 UPDATE ... WHERE id=1），粒度小，并发高。
- 表锁：对整个表加锁（如 LOCK TABLES ...），粒度大，并发低，一般不建议使用。
- 意向锁、间隙锁等：解决幻读、死锁等问题（后续单独讲解）。
六、常见问题与优化建议
- 事务死锁
- 现象：两个事务互相等待对方释放锁（如事务 A 锁记录 1，等待记录 2；事务 B 锁记录 2，等待记录 1），导致卡住。
- 解决：避免长事务；操作表时按固定顺序访问记录；通过SHOW ENGINE INNODB STATUS查看死锁日志，优化 SQL。
- 长事务风险
- 问题：长事务会占用锁和 undo log，导致并发下降、回滚日志膨胀。
- 建议：拆分事务（如将 "批量插入 10 万条数据" 拆分为多个小事务）；避免在事务中执行非数据库操作（如调用外部接口）。
- 隔离级别选择
- 并非级别越高越好：串行化虽安全，但并发能力极差（类似单线程），适合极少数核心场景。
- 推荐：互联网业务优先用 "读已提交" 或默认的 "可重复读"，平衡一致性与性能。
七、总结
事务是 MySQL 保证数据一致性的核心，掌握 ACID 特性、隔离级别和基本操作是后端开发的必备技能。关键知识点：
- 事务是 "不可分割的操作单元"，通过 COMMIT 和 ROLLBACK 控制。
- ACID 中，原子性依赖 undo log，持久性依赖 redo log，隔离性依赖 MVCC 和锁。
- 四种隔离级别对应不同的并发场景，默认 "可重复读" 适用多数业务。
- 实战中需避免长事务、死锁，合理选择隔离级别。
如果觉得有帮助，欢迎点赞收藏！后续会更新 "事务死锁排查""MVCC 底层详解" 等内容，关注不迷路～有问题可以在评论区留言交流！