1. 一次支付订单事故让我重新审视事务处理前阵子深夜值班线上监控突然弹出告警支付订单表出现多笔重复扣款部分订单金额不降反涨还有几笔对账不平。排查下来问题出在同事写的转账逻辑上——先扣A账户余额、再给B账户加余额、最后写流水中间有一次网络抖动导致第三步超时第二步在重试机制下重复执行。如果这三步包在一个数据库事务里要么全部成功要么全部失败后面根本不会有这些麻烦。这类问题在日常开发中太常见了。凡是和钱、库存、状态、名额打交道的系统都绕不开数据库事务处理。它是保证数据正确性的最后防线也是并发场景下最容易出幺蛾子的地方。我见过不少同学对事务的理解停留在begin、commit、rollback三件套但一遇到隔离级别怎么选、死锁怎么排查、崩溃恢复怎么保证不丢数据就完全没思路。这篇内容就以我实操中的案例为主线把事务处理从原理到落地、从配置到排错完整梳理一遍适合所有写业务代码的开发者、刚接触数据库运维的同行还有想系统理解事务机制的同学。2. 事务到底在防什么从脏数据事故看ACID的日常意义2.1 没有事务的转账场景有多危险先说一个最简单的模型用户A向用户B转账100元。涉及两条SQLUPDATE accounts SET balance balance - 100 WHERE id A; UPDATE accounts SET balance balance 100 WHERE id B;如果这两条SQL之间数据库突然崩溃第一条执行了、第二条没执行结果就是A的钱凭空消失B没收到钱。这就是资金类系统最害怕的部分成功。再叠加并发A同时给B和C各转100元两条请求同时读取A的余额是200元各自扣减100后写回最终余额变成100元而不是0元。钱凭空多出来了。事务就是干这个的。它把一组操作打包成一个不可分割的执行单元保证要么全部生效、要么全部不生效同时让并发操作之间互不干扰。2.2 用真实故障对照ACID四个特性原子性Atomicity对应上面转账的例子。事务中任意一条SQL失败整个事务回滚到起点已执行的所有SQL全部撤销。我的习惯是在代码里这么写每个事务必须有明确的try-catchcatch到异常必须rollback再抛出去给上层处理绝不能吞异常。Connection conn dataSource.getConnection(); try { conn.setAutoCommit(false); // 扣余额 updateA(conn, 100); // 加余额 updateB(conn, 100); // 写流水 insertLog(conn, A to B, 100); conn.commit(); } catch (Exception e) { conn.rollback(); logger.error(转账事务失败已回滚, e); throw e; } finally { conn.close(); }一致性Consistency事务执行前后数据库的完整性约束、业务规则不能被破坏。比如余额不能为负、主外键必须匹配。一致性是应用层和数据库层共同保证的数据库负责约束业务代码负责业务规则。隔离性Isolation并发事务之间不能互相看到中间态数据。两个事务同时改同一行一个没提交之前另一个不应该读到它修改到一半的值。隔离级别不同能看到的东西也不同这块最容易踩坑后面单独展开。持久性Durability事务一旦提交效果永久保留。哪怕立刻断电重启已提交的数据也不能丢。这个靠redo log保证后面第三部分细讲崩溃恢复。2.3 我处理过的最典型的两种事故类型一类是事务被吞开发同学用Spring的Transactional方法内捕获了运行时异常并返回没有往外抛Spring认为事务正常结束结果该回滚的数据全部提交了。另一类是长事务拖垮整个库有人在一个事务里执行大量耗时的批量更新或者调外部接口导致事务开启时间过长锁一直不释放后面所有请求全部堵在锁等待上直接把连接池打满数据库响应时间飙升。这两种事故几乎每周都能在社区、工作群里看到。理解事务的ACID只是第一步真正会出事的地方全在边界条件上。3. 隔离级别选择为什么默认配置不等于最佳配置这一节是整个事务处理里最考人的地方。隔离级别决定了并发事务之间的可见性选错了轻则数据错乱重则业务逻辑完全不可信。3.1 三种并发异常及其现实案例脏读Dirty Read事务A修改了一行数据但还没提交事务B读到了这个未提交的中间值。如果A最终回滚B用到的就是永远不存在的脏数据。现实中典型场景统计报表和业务写入并发一个事务正在批量更新订单状态另一个事务读到了中间状态统计数字完全不对。不可重复读Non-Repeatable Read事务A先读订单金额为100元事务B随后把它改成120元并提交事务A再次读取同一条记录拿到的是120元。同一个事务内两次读的结果不一样。典型场景导出报表时同一个数据在不同时间点读出来不同导致对账差一分钱。幻读Phantom Read事务A按条件查出5条满足条件的数据事务B插入一条同样满足条件的新数据并提交事务A再次执行同样的查询多出来一条。典型场景用户下单时判断是否存在未支付订单第一次判断不存在另一个事务插入了一条用户就能重复下单支付。3.2 四种隔离级别的对照与选型数据库标准定义了四个级别不同数据库实现和默认值还不一样隔离级别脏读不可重复读幻读典型场景读未提交Read Uncommitted可能可能可能基本不用读已提交Read Committed避免可能可能大多数业务默认选项可重复读Repeatable Read避免避免部分避免报表、对账、资金类串行化Serializable避免避免避免极端一致性要求这里有两个经常被忽视的细节MySQL InnoDB的默认隔离级别是可重复读Oracle和PostgreSQL默认是读已提交。MySQL之所以默认RR是因为它在RR级别下通过MVCC和间隙锁Next-Key Lock把幻读也一并解决了成本相对可控。PostgreSQL则更倾向业务需要什么级别就去设置什么级别把更多控制权交给应用。我在生产环境中的选择逻辑是这样的普通OLTP业务点查、订单、用户信息更新读已提交足够隔离级别越低并发能力越强锁竞争越小。资金对账、库存扣减、优惠券发放这类必须保证同一事务内多次读取结果一致的场景可用可重复读。真的到了必须杜绝所有并发异常的场合才考虑串行化但要明确接受吞吐量下降的代价。3.3 MVCC和锁隔离级别背后的实现逻辑读已提交和可重复读之所以能避免脏读和不可重复读靠的是多版本并发控制MVCC。简单说数据库在行数据后面保存多个版本每个事务看到的是某个时间点的快照版本而不是最新值。读已提交下每次SELECT都会生成一个新的快照所以两次SELECT看到的内容可能不同——这就是不可重复读的来源。可重复读下事务第一次SELECT时生成快照事务内所有后续SELECT都基于这个快照保证了可重复读。MySQL InnoDB还在RR级别用Next-Key Lock锁住索引范围阻止其他事务插入符合条件的新行从而顺带解决了幻读。理解了MVCC你就能明白为什么RR级别下写锁冲突仍然存在MVCC只解决读读不阻塞、读写不阻塞但两个事务同时写同一行还是要靠行锁串行化。这里给新手一个实用建议不要盲目把隔离级别一律调成串行化来求稳。串行化会让读操作也加锁性能下降非常明显。我在压测中看到过同一套写入逻辑从读已提交切成串行化后吞吐量直接掉了60%以上。4. 崩溃恢复机制为什么断电重启后已提交数据不丢事务处理的另一个硬核问题是数据库怎么保证提交了就不会丢。我用了很多年的MySQL每次模拟kill -9宕机再恢复数据都完好无损靠的就是redo log和undo log这套日志机制。4.1 WAL机制先写日志再改数据数据库写入时不是直接改磁盘上的数据文件而是先把修改记录追加写入redo logWrite-Ahead Logging预写日志然后才更新内存中的数据页最后在合适的时机刷盘。这样设计的核心原因随机写数据文件非常慢而顺序追加写日志很快。更重要的是崩溃恢复时数据库只需要重放redo log就能把已提交但还没来得及写入数据文件的修改恢复出来。举个例子假设你执行一条UPDATE把订单状态从待付款改成已付款。数据库内部的动作顺序大致是把修改写入redo log buffer内存把对应数据页读入Buffer Pool并修改内存提交时把redo log刷到磁盘返回事务提交成功给应用之后某个时间点异步把脏数据页刷到磁盘数据文件如果第5步还没执行就断电重启后InnoDB扫描redo log发现某个数据页版本落后就重放日志把数据补齐。这就是已提交数据不丢的原因。4.2 undo log承担回滚和MVCC的底账和redo log配套的是undo log。每次事务修改数据前InnoDB会把旧值写入undo log这样一旦事务回滚就能从undo log里把旧值找回来还原。同时MVCC生成快照时也是靠undo log回溯历史版本。一个事务在RR级别下创建的快照能够通过undo log链一直往之前翻直到找到符合自己可见性条件的版本。注意undo log带来一个隐患长事务会导致undo log文件持续膨胀。事务不结束里面涉及的旧版本就无法清理占用大量空间极端情况下还会拖慢查询。我在生产环境遇到过一个大事务跑了快2个小时undo表空间从10GB涨到80GB简直是存储杀手。4.3 checkpoint崩溃恢复耗时背后的关键角色崩溃恢复不会无限重放所有redo log。InnoDB会周期性做checkpoint把已经刷到数据文件的页标记为已检查点记录检查点LSN。恢复时只需要从最近一次checkpoint之后开始重放恢复时间大大缩短。检查点越频繁恢复越快但频繁刷盘对运行期性能有一定消耗。这个平衡通常由数据库自己控制。作为使用者你只需要知道一个结论崩溃恢复时间主要取决于checkpoint到崩溃点之间的日志量平时不要让系统长时间处于大量写入但迟迟不刷盘的极端状态。4.4 实测一次模拟崩溃恢复有一次内部演练我执行一个更新100万行的大事务跑到中途直接kill -9然后重启MySQL。启动日志显示InnoDB: Doing recovery: scanned up to log sequence point 2456789 InnoDB: 1 transaction(s) which must be rolled back InnoDB: Last MySQL binlog file position 0 654321重启完成后数据停留在事务开始前的状态没有部分更新。这就是原子性和持久性在真实崩溃场景下的配合已提交未落盘的部分由redo恢复未提交的部分由undo回滚。5. 锁竞争与死锁一次真实死锁的完整排查链路锁是事务实现隔离的手段也是并发问题最集中的爆发点。死锁几乎每个团队都遇到过但很多人的处理姿势是重启解决一切。出现这类问题时我的排查链路是固定的直接按这个流程走最快。5.1 死锁发生时的第一现场证据某次线上出现大量报错Deadlock found when trying to get lock; try restarting transaction。这是InnoDB抛出的典型死锁错误。此时第一件事不是重启应用而是立刻抓取现场。执行SHOW ENGINE INNODB STATUS\G重点看LATEST DETECTED DEADLOCK段落里面包含了死锁涉及的两个事务、它们各自持有什么锁、正在等待什么锁以及触发死锁的SQL。另一条实用SQL是SELECT * FROM performance_schema.data_lock_waits\G; SELECT * FROM information_schema.INNODB_TRX\G;前者能看到谁在等谁的锁后者能看到当前运行的事务、执行时间、是否处于锁等待。5.2 还原我的死锁现场那次死锁涉及的逻辑很典型事务A先更新订单表WHERE id1再更新用户表WHERE id100事务B先更新用户表WHERE id100再更新订单表WHERE id1两个事务各自持有第一把锁又都在等待对方持有的第二把锁互不相让死锁发生。InnoDB检测到死锁后会回滚其中一个事务通常是代价较小的那个另一个继续执行。所以死锁其实不会无限阻塞但应用层收到的报错就是上面那句。这类问题的根因是多个事务对多个资源的加锁顺序不一致。规则性操作容易出现这种问题。5.3 从根因到治理方案解决死锁我通常按优先级做这几件事统一资源访问顺序所有事务都按同一顺序加锁比如先用户后订单、先小ID后大ID。这是最根本的解法从代码层面就杜绝交叉等待。缩短事务执行时间事务里不要查大量无关数据更不要把RPC调用、HTTP请求、文件读写放进事务。持有锁的时间越短和其他事务交错的概率越低。检查索引是否合理如果UPDATE的WHERE条件没有索引InnoDB会锁住整张表死锁概率指数级上升。执行EXPLAIN确认UPDATE语句走的是索引。降低隔离级别某些死锁场景是间隙锁Next-Key Lock造成的这部分锁在RR级别下尤为复杂。如果业务不要求完全阻止幻读把隔离级别降到读已提交间隙锁不再产生很多死锁自然消失。合理设置锁等待超时innodb_lock_wait_timeout默认50秒可以适当调低避免一个事务等待锁太久拖垮应用。但要权衡过低会影响正常的并发业务。5.4 锁的类型一张表讲透排查死锁时还需要先识别锁的类型。InnoDB的锁体系里我常用到这几类锁类型作用范围常见触发备注共享锁S锁行SELECT ... LOCK IN SHARE MODE允许其他事务继续加S锁排他锁X锁行UPDATE、DELETE、SELECT ... FOR UPDATE和任何其他锁互斥意向锁表加行锁前自动加标记表级别有行锁间隙锁索引范围RR级别下的范围查询防止幻读但容易引发死锁记录锁单行索引等值查询命中索引最常规的行锁元数据锁MDL表结构DDL操作会阻塞所有读写要特别小心有一条铁律对排查死锁特别有帮助只要两个事务都只操作一行数据理论上不会死锁除非自旋锁等内部原因。死锁的本质是资源获取顺序不对所以排查优先看多个资源、多行数据、范围锁定的场景。6. 应用层事务实践连接池、事务边界与几个血泪教训事务处理不只是数据库内部的事应用层的写法直接决定事务行为。这一节整理的内容全是我在实际项目里踩过坑之后沉淀下来的。6.1 连接池复用与事务的绑定关系很多人忽略了一个关键细节数据库事务是绑定在数据库连接Connection上的。连接池里的连接是复用的如果你在代码里拿到了连接A开启事务中途换成了连接B那事务就废了。常见错误写法// 错误示例先getConnection开启事务方法中又getConnection Connection conn1 dataSource.getConnection(); conn1.setAutoCommit(false); // 某个查询内部又调用了 dataSource.getConnection() 获取新连接 doQuery(dataSource); // 内部连接不是conn1不在同一事务 conn1.commit();正确做法是整个事务的所有数据库操作必须使用同一个连接对象。在Spring里Transactional之所以有效是因为Spring把连接绑定到了当前线程后续ThroughTransaction管理的数据源获取到的是同一个连接。一旦你在事务方法里绕过了Spring的数据源、直接new了一个新的连接事务就断开了。另外要注意连接池中连接关闭不等于物理断开commit之后连接归还池里下一个事务拿到的是同一个连接。如果上一个事务没有正确commit或rollback就归还连接下一个事务会继承未完成的脏状态这是事务穿越的经典成因。6.2 显式事务的三段式书写规范我推荐在所有非框架项目的数据库代码里都采用明确的获取连接、关闭自动提交、try-catch-commit/rollback-finally-close三段式结构。代码长一点但每一处的边界都清清楚楚Connection conn null; try { conn dataSource.getConnection(); conn.setAutoCommit(false); conn.setTransactionIsolation(Connection.TRANSACTION_READ_COMMITTED); // 业务操作1.更新账户 2.更新流水 3.更新订单状态 accountDao.deduct(conn, userId, amount); flowDao.insert(conn, userId, amount); orderDao.updateStatus(conn, orderId, PAID); conn.commit(); } catch (Exception e) { if (conn ! null) conn.rollback(); log.error(事务执行失败已回滚, e); throw new BizException(操作失败, e); } finally { if (conn ! null) conn.close(); }事务边界要尽量小最好只在真正需要原子的几步操作上开启不要一个大方法从头到脚全包在里面。我见过把查询日志、调用通知接口都放进事务的代码这种坏习惯对生产环境的伤害极大。6.3 隐式提交这个隐蔽的坑MySQL里DDL语句CREATE、ALTER、DROP、TRUNCATE会导致当前事务隐式提交。也就是说你在一个事务中间执行了一条ALTER TABLE前面已经做的修改立刻永久提交后面再rollback也回不去了。这个坑很容易出现在程序里动态改表结构的骚操作中基本是灾难。另外设置了autocommit1时每条SQL执行完都自动提交此时begin、commit的意义就不大了。所以检查自己的数据源配置确认默认行为是符合预期的。6.4 长事务和多线程操作事务的禁忌长事务的危害我在前面提过这里再强化一下持有锁时间过长导致其他事务大量阻塞最终连接池被耗尽。undo log膨胀占用大量磁盘空间。主从复制延迟增大因为一个长事务在备库上的回放也需要很久。事务里的数据版本链过长任何基于MVCC的查询都会变慢。多线程操作事务的坑更隐蔽。我处理过一起事故一个任务用线程池并发跑大量小事务但每个线程的代码里通过ThreadLocal传递了同一个事务上下文结果把几个独立事务串成了一个假事务一个线程回滚把其他线程的提交也带崩了。正确的做法是每个线程自己获取连接、自己开事务、自己提交/回滚绝对不要在多个线程里共享同一个连接。6.5 参数配置层面的几条建议最后给一组我实测过、适合大多数中小型业务系统的参数组合参考参数推荐值说明innodb_lock_wait_timeout5~10秒锁等待超过这个时间报错避免无限等innodb_rollback_on_timeoutON超时后回滚整个事务避免部分提交max_execution_time根据业务设置防止单个SELECT跑太久占用连接transaction_isolationREAD-COMMITTED多数场景/ REPEATABLE-READ资金对账按业务选别默认不调lock_wait_timeout和上面配套元数据锁等待场景也有作用参数不是越多越好核心思路是先想清楚业务的并发模型和事务边界再决定隔离级别、超时时间和锁策略。反过来盲目照抄大厂参数大概率水土不服。最后分享一个我自己的经验凡是容易出现事务问题的系统排查思路永远先看三件事——事务边界是否清晰、隔离级别是否匹配业务、资源访问顺序是否一致。这三件事搞清楚了80%的事务故障都能提前避免。我现在的习惯是在每次上线事务密集型项目前强制做一轮事务场景走查把热点SQL的EXPLAIN、潜在的长事务、跨资源加锁顺序都过一遍。这个习惯帮我挡掉了很多线上事故你也值得试试。