运维实习手记：MySQL事务精准控制实战

　　刚接手运维实习的第三天，就遇到一个棘手问题：财务系统凌晨批量扣款时，部分订单状态更新失败，但资金却已扣除。日志显示SQL执行成功，可业务侧数据不一致。导师没直接给答案，只递来一张纸条：“查事务隔离级别，看autocommit是否关闭。”

　　我立刻登录测试库执行SELECT @@transaction_isolation, @@autocommit; 结果是REPEATABLE-READ和1——自动提交开着。这意味着每条UPDATE都是独立事务，一旦中间某步出错（比如下游接口超时），前面的资金扣减无法回滚。真正的业务逻辑本该包裹在BEGIN…COMMIT块中，形成原子操作。

　　我们复现了问题场景：模拟扣款脚本先UPDATE account SET balance = balance - 100 WHERE id = 123; 再UPDATE order SET status = 'paid' WHERE id = 456; 最后调用外部支付网关。当网关返回超时，脚本未捕获异常，第二条UPDATE未执行，但余额已减少。修复方案很直接：在应用层显式开启事务，用try-catch包裹全部SQL，并在catch中执行ROLLBACK；同时将数据库连接的autocommit设为0。

　　但新问题浮现：并发下单时，两个事务同时读取同一账户余额，各自扣减后提交，导致超扣。导师让我运行SELECT FROM information_schema.INNODB_TRX; 观察trx_state和trx_query字段。果然，多个事务卡在“LOCK WAIT”状态。根源在于默认隔离级别下，普通SELECT不加锁，而UPDATE会加行锁但需等待前序事务释放。解决方案是改用SELECT ... FOR UPDATE，在读取余额时即锁定该行，确保后续UPDATE串行执行。

AI生成结论图，仅供参考

　　上线前我们做了压力测试：用sysbench模拟200并发转账。起初TPS仅80，错误率12%；加入FOR UPDATE后TPS升至190，错误归零。更关键的是，通过SHOW ENGINE INNODB STATUS\\G 查看死锁日志，发现两个事务按不同顺序访问表（A→B vs B→A）。于是统一所有业务模块的SQL执行顺序：始终先操作account表，再操作order表，彻底规避循环等待。

　　一周后复盘，导师指着监控图说：“事务不是越长越好，也不是越短越安全。”他让我对比两组慢查询日志：一组是单事务内执行37条INSERT，耗时2.3秒；另一组拆成5个短事务，总耗时1.1秒且锁持有时间缩短80%。原来事务边界必须贴合业务语义——资金扣减与订单状态变更必须同事务，但日志记录、消息推送等非核心步骤应剥离出去异步处理。

　　现在每次上线前，我都会用pt-deadlock-logger抓取死锁，用performance_schema.events_statements_summary_by_digest分析长事务。MySQL事务不是黑盒开关，而是需要感知锁粒度、隔离语义、应用交互节奏的精密协奏。一次精准的ROLLBACK，有时比十次成功的COMMIT更能体现运维对数据生命的敬畏。

（编辑：92站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!