MySQL事务控制无障碍设计指南

　　去年七月那回，我原以为只是普通的事务卡顿，结果整出个半夜爬起来救火的破事儿。开发那边提交了个批量更新脚本，说测试环境跑得挺顺——可测试环境就三台机器，数据量还没我手机相册大。生产环境一上，好家伙，好几台从库的binlog直接卡成幻灯片，主库的事务堆积得比值班表上的待办还长。我盯着监控屏幕，事务等待数蹭蹭往上涨，手机还震个不停，全是告警消息，开发在群里喊“怎么还没好”，我手都抖了，泡面都没吃完，汤都凉了。

　　当时第一反应是查锁——SHOW ENGINE INNODB STATUS看了三遍，死锁日志倒是没见着，可有个事务拿着排他锁，愣是等了快二十分钟没释放。我原以为肯定是哪个SQL没加索引，结果EXPLAIN一看，索引全在，就是事务里混了条“先查后改”的逻辑——先SELECT FOR UPDATE锁了行，再根据结果决定是UPDATE还是DELETE。这逻辑本身没问题，可开发没给SELECT加LIMIT 1，好家伙，直接锁了整张表里符合条件的两万多行。从库那边同步线程卡着，主库的undo日志涨得比磁盘IO还快，我盯着屏幕，窗外天都快亮了，机房的空调吹得我脚脖子发凉。

　　其实这事儿要搁平时，直接KILL掉长事务就行——可那天偏偏赶上月底备份，三台机器里两台的备份线程还在跑，KILL命令发出去，主库的事务倒是断了，可从库的同步直接报错，binlog位置对不上，得手动跳过。我蹲在机房里，对着命令行敲“SET GLOBAL sql_slave_skip_counter=1”，敲完手心全是汗，生怕跳过的事务里有重要数据。开发在旁边嘀咕：“这MySQL的事务控制也太脆了吧？”我火大，回他：“脆不脆看怎么用！你们写的脚本，锁表跟玩似的，再健壮的系统也扛不住啊！”

　　后来复盘的时候，我翻出那本《MySQL事务控制无障碍设计指南》，翻到“事务粒度控制”那章，突然觉得这书里说的“优胜劣汰”挺在理——不是所有操作都得塞进一个事务里，该拆的拆，该短跑的别搞马拉松。比如那个卡死的事务，完全可以拆成两个：先查，拿到结果后再开新事务改。这样就算查的时候锁了行，改的时候锁的时间也短，从库同步压力小，主库的undo日志也不会疯涨。我原以为开发都懂这些基本原则，结果一问，好家伙，他们觉得“事务里操作越多越安全”——安全个鬼！安全的是数据，累死的是运维。

　　其实那天最气人的不是事务卡死，是备份没跑完就出问题。我原以为备份脚本里加了“--single-transaction”，就算有长事务也不会锁表——结果后来查日志才发现，备份线程和那个卡死的事务用的是同一个连接池，事务没释放，备份线程拿不到一致性快照，直接卡在那儿等。等我处理完事务，备份已经超时失败，还得手动重跑。机房的灯亮得刺眼，我盯着屏幕上的“Backup failed”，心想这破事儿本来能避免的，要是开发能多看看那本设计指南，或者运维能早点介入代码审查……

　　跟开发吵完那架后，我把那本指南拍在他们工位上，重点标了“事务隔离级别选择”“锁超时设置”“短事务优先”这几章。他们翻了几页，说“这书里写的倒挺实在，可我们平时哪顾得上这些？”我冷笑：“顾不上就等着半夜爬起来救火吧！”其实我也知道，他们压力大，产品催得紧，代码写得急——可再急，也不能拿事务当垃圾桶，什么都往里塞啊。后来我定了个规矩：所有涉及数据修改的脚本，必须先过运维的代码审查，重点看事务粒度和锁使用。开发一开始还抱怨，后来出了两次类似的事儿，现在倒主动找我讨论事务设计了。

文章配图，仅供参考

（编辑：站长网）

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