摘要：作为互联网软件开发人员，你是不是也遇到过这样的场景？在写订单支付功能时，明明代码逻辑看着没问题，却偶尔出现 “用户付了钱，订单状态却没更新” 的情况；或者在批量同步数据时，执行到一半报错，结果部分数据成功、部分失败，后续还要手动清理一堆 “烂摊子”。如果你也踩
作为互联网软件开发人员，你是不是也遇到过这样的场景？在写订单支付功能时，明明代码逻辑看着没问题，却偶尔出现 “用户付了钱，订单状态却没更新” 的情况；或者在批量同步数据时，执行到一半报错，结果部分数据成功、部分失败，后续还要手动清理一堆 “烂摊子”。如果你也踩过类似的坑，那大概率是没把 MySQL 的事务处理机制用明白 —— 今天咱们就好好聊聊这个能帮你 “保住数据准确性” 的核心技术，让你以后写数据库相关代码时更有底气。
在聊具体机制前，咱们得先明确一个问题：为啥 MySQL 要设计 “事务” 这个功能？其实答案很简单，就是为了解决 “多步操作下的数据一致性” 问题。
比如咱们常见的 “用户转账” 场景，要完成 A 用户向 B 用户转 100 元，得执行两步核心 SQL：第一步是 “扣减 A 的账户余额 100 元”，第二步是 “增加 B 的账户余额 100 元”。如果没有事务保护，万一第一步执行成功了，第二步却因为网络波动、数据库崩溃等问题失败了，会出现什么情况？A 的钱扣了，B 的钱没到账，这就成了 “单边账”，后续排查和修复会特别麻烦。
而事务的作用，就是把这 “多步操作” 打包成一个 “不可分割的整体”—— 要么所有操作都成功执行，要么所有操作都回滚到最初状态，绝对不会出现 “部分成功、部分失败” 的尴尬局面。对于咱们开发来说，掌握事务，就等于掌握了保障业务数据准确性的 “关键钥匙”。
聊事务，就绕不开 “ACID” 这四个字母 —— 这是事务的核心特性，也是咱们判断事务是否生效的关键标准，咱们一个个拆开来讲，保证你能理解。
原子性就像咱们平时玩的 “闯关游戏”，要么你闯过所有关卡通关，要么只要有一关失败，就回到游戏开始前的状态，不存在 “闯过 3 关、失败 2 关” 的中间态。
对应到数据库操作上，比如刚才说的转账场景，事务会把 “扣 A 的钱” 和 “加 B 的钱” 这两步操作当成一个 “原子”，只要其中任何一步执行失败（比如 SQL 报错、数据库断开连接），事务就会自动 “回滚”—— 把 A 被扣的钱加回去，B 没加上的钱也不会有记录，确保数据回到操作前的状态，不会出现 “钱少了” 的问题。
一致性指的是，事务执行前后，数据必须符合咱们定义的 “业务规则”，不能出现 “合法→非法” 的情况。
还是拿转账举例，假设 A 有 500 元，B 有 300 元，两人总余额是 800 元。不管事务执行成功还是失败，总余额都得是 800 元 —— 如果事务成功，A 变成 400 元、B 变成 400 元，总和还是 800 元；如果事务失败，A 还是 500 元、B 还是 300 元，总和依然不变。绝对不会出现 “A400 元、B300 元”（总和 700 元）这种不符合业务规则的情况，这就是一致性的核心要求。
隔离性主要解决的是 “多个事务同时执行时，互相影响” 的问题。咱们开发中，数据库往往不是只有一个人在用，可能多个用户同时操作同一张表 —— 比如两个事务同时修改用户的余额，要是不隔离，就容易出问题。
举个例子：假设 A 有 1000 元，现在有两个事务同时执行 “扣 A 500 元” 的操作。如果没有隔离性，第一个事务查 A 的余额是 1000 元，还没来得及扣钱，第二个事务也查 A 的余额，同样是 1000 元，然后两个事务都扣了 500 元，最后 A 的余额变成 0 元？但实际上两个事务总共扣了 1000 元，A 原本只有 1000 元，结果是对的？不对，要是第一个事务执行到一半回滚了呢？第二个事务已经扣了 500 元，就会导致 A 的余额变成 500 元，而第一个事务回滚后，本应恢复的 500 元没恢复，这就出问题了。
而隔离性就是给每个事务 “划了一道墙”，让它们在执行时 “看不到对方的中间状态”，避免这种互相干扰的情况。MySQL 提供了不同的隔离级别，咱们后面会具体说，你可以根据业务需求选择合适的级别。
持久性很好理解，就是事务一旦执行成功（也就是 “提交” 了），那么它对数据的修改就会 “永久保存” 在数据库里，就算之后数据库崩溃、服务器断电，重启后数据也不会丢失。
比如你执行了 “更新订单状态为已支付” 的事务，并且成功提交了，那就算下一秒数据库服务器突然断电，等服务器重启、数据库恢复后，这个订单的状态依然是 “已支付”，不会因为断电回到 “未支付” 状态。这是因为 MySQL 会把事务提交后的修改，持久化到磁盘上的日志和数据文件中，确保数据不会因为意外情况丢失。
理解了 ACID 特性，咱们再聊聊实战中怎么用事务，以及容易踩的坑怎么避开 —— 这部分内容直接关系到你写代码时的正确性，一定要仔细看。
MySQL 中使用事务很简单，核心就 3 个命令：开启事务、提交事务、回滚事务。咱们用一个 “订单支付” 的场景举例，看看具体怎么写：
-- 1. 开启事务（默认情况下MySQL是自动提交的，开启事务后会关闭自动提交）START TRANSACTION;-- 2. 执行核心业务操作（比如扣减库存、更新订单状态）UPDATE product SET stock = stock - 1 WHERE id = 1001; -- 扣减商品库存UPDATE order SET status = 'paid' WHERE order_no = '20240520001'; -- 更新订单为已支付-- 3. 判断是否执行成功：成功则提交，失败则回滚COMMIT; -- 所有操作都成功，提交事务，修改生效-- ROLLBACK; -- 若有操作失败，执行回滚，所有修改恢复原状在实际开发中，你不会直接手动执行这些 SQL，而是会在代码里通过 ORM 框架（比如 MyBatis、Spring Data JPA）来控制事务。比如在 Spring 框架中，只需要在方法上加上@Transactional注解，就能自动开启事务 —— 当方法里所有 SQL 都执行成功时，自动提交；只要有一行 SQL 报错（比如抛出异常），就自动回滚，特别方便。
刚才咱们提到了隔离性，MySQL 为了平衡 “隔离效果” 和 “性能”，提供了 4 种隔离级别，不同级别应对的场景不同，选错了就容易出问题。咱们先搞懂这 4 种级别，再说说怎么选。
（1）4 种隔离级别及其效果
从 “隔离程度低” 到 “隔离程度高”，MySQL 的 4 种隔离级别分别是：
读未提交（Read Uncommitted）：最低级别，一个事务能读到另一个事务 “未提交” 的修改。这种级别会出现 “脏读”（比如读到了别人没提交的临时数据，结果对方回滚了，你读的数据就成了 “脏数据”），实际开发中几乎不用。读已提交（Read Committed）：一个事务只能读到另一个事务 “已提交” 的修改。这种级别能避免 “脏读”，但会出现 “不可重复读”—— 比如同一个事务中，两次查询同一条数据，结果不一样（因为中间有另一个事务提交了修改）。比如你在事务中第一次查 A 的余额是 1000 元，还没处理完，另一个事务扣了 A 500 元并提交，你再查 A 的余额就变成 500 元了，这就是 “不可重复读”。可重复读（Repeatable Read）：MySQL 的默认隔离级别。同一个事务中，多次查询同一条数据，结果始终一致，就算中间有其他事务修改并提交了，也看不到。这种级别能避免 “脏读” 和 “不可重复读”，但会出现 “幻读”—— 比如你在事务中查询 “余额大于 500 元的用户”，第一次查到 10 个，然后另一个事务新增了一个余额 600 元的用户并提交，你再查还是 10 个（因为可重复读级别下，事务会 “记住” 第一次查询的结果），但如果你尝试插入一个 “余额大于 500 元” 的用户，却可能提示冲突，就像看到了 “幻觉” 一样。串行化（Serializable）：最高级别，完全隔离，多个事务对同一条数据的操作会 “排队执行”（相当于单线程），不会有任何干扰。这种级别能避免所有问题，但性能极低，只适合数据一致性要求极高、并发量极低的场景（比如财务对账），一般业务不用。（2）怎么选隔离级别？
大多数情况下，你不用改，直接用 MySQL 默认的 “可重复读” 就够了 —— 它能满足 90% 以上的业务场景，既保证了数据一致性，又不会有太大的性能损耗。
如果你的业务对 “不可重复读” 不敏感（比如统计实时数据，允许同一事务中两次查询结果有差异），也可以把隔离级别设为 “读已提交”，性能会更好一些。比如做用户行为分析，统计某分钟内的点击量，就算中间有数据更新，两次查询结果不一样，对最终统计影响不大，这种场景就可以用 “读已提交”。
至于 “读未提交” 和 “串行化”，除非有特殊需求，否则别用 —— 前者数据太不安全，后者性能太差。
就算你加了@Transactional注解，或者手动写了START TRANSACTION，也可能因为一些小细节导致事务失效，咱们盘点几个最常见的坑：
（1）方法不是 public 的
Spring 的@Transactional注解只对 public 方法生效，如果你的方法是 private、protected 或者默认访问权限，注解会失效，事务不会开启。比如：
// 错误：private方法，@Transactional无效@Transactionalprivate void updateOrderStatus(String orderNo) { // 业务逻辑}// 正确：public方法@Transactionalpublic void updateOrderStatus(String orderNo) { // 业务逻辑}（2）捕获了异常却没抛出
如果你的方法里用 try-catch 捕获了异常，却没有重新抛出，Spring 会认为 “方法执行成功”，不会触发回滚。比如：
@Transactionalpublic void payOrder(String orderNo) { try { updateProductStock; // 扣库存 updateOrderStatus; // 更新订单 } catch (Exception e) { // 错误：只打印日志，没抛出异常，事务不会回滚 log.error("支付失败", e); }}// 正确：捕获后重新抛出，让Spring感知到异常@Transactionalpublic void payOrder(String orderNo) { try { updateProductStock; updateOrderStatus; } catch (Exception e) { log.error("支付失败", e); throw new RuntimeException("支付失败", e); // 重新抛出异常 }}（3）用了不支持事务的存储引擎
MySQL 中，只有 InnoDB 存储引擎支持事务，MyISAM 引擎是不支持的。如果你建表时用了 MyISAM 引擎，就算写了事务代码，也不会生效。所以建表时一定要指定 InnoDB 引擎，比如：
-- 正确：指定InnoDB引擎CREATE TABLE order ( id INT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(50) NOT NULL, status VARCHAR(20) NOT NULL) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;看到这里，相信你对 MySQL 事务处理机制已经有了清晰的认识 —— 从 ACID 特性到实际使用方法，再到避坑重点，这些内容都是咱们开发中天天会用到的核心知识。
最后想跟你说：事务不是 “可有可无” 的技术，而是保障业务数据准确性的 “底线”。比如订单、支付、库存这些核心模块，一旦事务用错了，就可能出现数据混乱，进而引发用户投诉、业务损失，甚至更严重的问题。
所以，建议你看完这篇文章后，回头检查一下自己项目中的事务使用情况：比如核心方法有没有加事务注解？隔离级别是不是选对了？有没有可能导致事务失效的坑点？把这些细节做好，你的代码会更 “靠谱”，也能帮你避开很多线上故障。
如果你在实际使用中遇到了具体问题，比如事务回滚不生效、隔离级别导致的异常场景，欢迎在评论区留言，咱们一起讨论解决 —— 技术就是在不断交流和实践中进步的，对吧？
来源：从程序员到架构师