Ruby老兵亲授：MySQL设计与运维实战手册

　　凌晨三点被监控告警震醒，屏上并排三个终端闪得眼疼——主库负载飚到28，从库慢查询堆了四百多条，而隔壁工位的老张正叼着半根烟改配置，泡面汤滴在跳板机键盘上，粘得我按了三次F5才刷出慢查询日志。这场景我原以为只在刚入行时见过，结果上周又撞上一次——你猜怎么着？最后救场的不是那堆花里胡哨的监控大屏，是十六年前我师父手写的MySQL优化手册，封皮都卷边了，可里头那句"索引不是越多越好"到现在都没过时。

　　那天故障的导火索特蠢：开发新上线的订单系统，为了"提升查询效率"给用户表加了七个复合索引，结果半夜促销活动一来，写操作直接把主库CPU干穿。我原以为现在的年轻人早该明白"索引维护成本"这回事，结果翻监控才发现，他们连explain的输出都看不利索——type列显示ALL就慌了，也不管rows扫了多少，咔咔咔全加索引。最绝的是有个索引字段顺序还是反的，把高频查询的字段放⭐️⭐️⭐️⭐️导致索引根本没生效，慢查询日志里全是全表扫描的记录。

文章配图，仅供参考

　　上周那场故障最后怎么解决的？先把非核心业务的连接数砍了三分之二，让主库喘口气；然后手动杀掉那些卡了半小时的慢查询——别笑，现在有些ORM框架默认不设超时，一个查询能挂半小时；最后把多余的索引全删了，只留三个最常用的。你猜恢复后负载多少？从28降到0.8，慢查询直接归零。开发同事盯着监控图愣了半天，说："原来不用加索引也能这么快？"我指了指那本卷边的手册："你师父的师父传下来的，优胜劣汰——能活到现在的优化手段，都是被故障锤出来的。"

　　说到手册，里头有段话我现在看都觉得扎心："别信那些'高可用架构图'，真正救命的永远是最土的办法：主从切换脚本要能闭着眼敲，备份文件要能随时拉起来跑，监控告警别只设阈值，得看趋势——比如负载从2涨到5可能没事，但从5跳到20肯定有问题。"上周故障时，云厂商的监控显示"一切正常"，可我们自己的脚本早就发现慢查询数在半小时内翻了十倍——要不是有这层保险，等云厂商的工单排到，促销活动都结束了。

　　跟老板争执那次更逗：他非要把所有业务都上云，说"省运维成本"。我翻出2018年的记录：那年云数据库宕机两次，每次恢复都要找云厂商要权限，最久的一次等了四小时——那会儿我们还在用自建机房，磁盘坏了自己换，十分钟搞定。老板说："现在云厂商承诺99.99%可用性。"我指着手册里那行字："可用性是算出来的，不是保出来的——你见过哪个云厂商敢承诺'故障时五分钟内给你操作权限'？"他没说话，后来偷偷让我留了份自建机房的扩容方案。

　　其实最让我后怕的不是故障，是那些"没发生的故障"。比如上个月，开发同事说要给用户表加个JSON字段存偏好，我扫了眼手册里"JSON字段的查询陷阱"那章，让他先在测试库跑explain——结果发现全表扫描，因为JSON字段没法建普通索引。要不是我多问了一句，这代码上线后，主库负载怕是要再飚一次。现在有些新人觉得"MySQL是成熟产品，不会出大问题"，可他们没经历过2010年那场inode耗尽的事故——当时日志文件把磁盘占满，数据库直接挂掉，恢复时发现备份脚本早就没跑，最后是从三个月前的物理备份里抠数据，丢了整整两天的订单。

　　现在看，运维这行没什么"新招"，都是老把戏反复用。比如手册里写的"定期检查磁盘空间"，现在云数据库虽然不用自己管磁盘，但得盯着存储配额——上周就有个业务把日志级别调成DEBUG，三天就把500G配额占满，数据库又挂了一次。还有"监控慢查询趋势"，现在云厂商的监控能显示慢查询数，但看不出哪些SQL是新增的——我们自己写了脚本，把慢查询按出现频率排序，新出现的直接标红，上周就靠这招逮到两个漏网的全表扫描。

　　椅子轮子卡着的那根网线，是上周扩容时扯断的，到现在还没修——运维这行就这样，永远有修不完的破事儿。可有些破事儿不能不修，比如那本卷边的手册，我上周又往里加了页：记的是云数据库的权限管理陷阱——现在云厂商的IAM策略比MySQL的权限系统还复杂，稍不注意就把自己锁外面。开发同事笑我"老古董"，可等他们半夜被叫起来修故障时，第一个翻的准是这本手册——优胜劣汰嘛，能活到现在的，都是被故障锤出来的。

　　下次再有人跟我说"MySQL运维有什么难的"，我就把这本手册甩他脸上——16年，278页，每页都是血泪换来的。云厂商的SLA再高，也保不了你手抖删错表；监控大屏再炫，也替你看不了binlog。有些东西，真得靠时间熬出来。

（编辑：站长网）

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