MySQL运维与设计实战：11年测试工程师的稳定高效之路

　　去年夏天，运维组把主库从5.7升到8.0，没通知测试侧，只在钉钉群里甩了个截图——就是那个绿色带钩的“已执行”，底下跟了三个点赞表情包，其中一个是老张发的，用的是他儿子拍的柴犬舔手机屏那张。我盯着那图看了十八秒，没点开链接，直接切到监控看QPS曲线，发现凌晨三点十七分有段尖刺，不是抖动，是断崖式掉下去又弹回来，像被谁拿鼠标点了两次“重启服务”。

　　我说“这不叫平滑迁移”，老张回了个翻白眼emoji，然后补了一句：“你们测的又不是数据库，是业务逻辑。”我原以为他在抬杠，结果第二天早上八点二十三，CDN层缓存全崩，蜘蛛来了一批就走了，收录量单日跌了三百七十二条——这数我记得清楚，因为当时正蹲在机房门口啃冷掉的韭菜盒子，纸盒底还沾着半粒孜然，监控大屏就在头顶滋啦响，像老式收音机调频失败时的杂音。

　　我们测CMS，从来不是测“MySQL能插能查”，是测它在半夜三点十七分、当某个运营在后台点“批量下架五百个SKU”、同时另一个前端正在往富文本里粘贴带二十六个嵌套表格的HTML、而第三个接口正把JSON里的price字段当字符串拼进SQL时，还肯不肯吐出一个HTTP 200。这种事不写在任何文档里，但你只要盯过三天慢查询日志，就能闻出来哪条语句在憋着坏——就像闻得出泡面桶里那股油炸味混着隔夜茶渍的酸气。

　　前两天又被拉进一个会，讲“高可用架构升级路径”。PPT第十二页写着“主从延迟≤50ms为健康态”，我就问了一句：“上次双十一凌晨四点，从库延迟冲到两秒，为什么告警只响了十秒？”没人答。会议室空调嗡嗡响，窗台上那只死了三年的绿萝还剩半截枯茎，根须干成灰白色，蜷在盆沿。后来小王偷偷说，监控脚本里那个timeout阈值，是他们上线当天随手写的，写了10000毫秒，后面一直没人改。我信这个，因为我知道那脚本跑在一台连systemd都懒得启的旧容器里，IP地址后三位是092，和我工位编号一样。

文章配图，仅供参考

　　（这时候我手机震了一下，是运营群，@我问“为什么搜索关键词‘云服务器’不出首页前三”，我没回。那边紧接着发了个截图：首页前三全是竞品广告，标着“官方推荐”，字体比我们自己的标题还大半号。）

　　最扯的一次是去年六月，一个SELECT COUNT()卡住四十分钟，最后发现是InnoDB统计线程被一个没加WHERE的UPDATE锁住了元数据表。不是死锁，是单向阻塞。DBA说是“正常设计”，我问他：“那你告诉我，这个‘正常’是按哪年哪月哪个commit日志定的标准？”他愣了两秒，转头去削铅笔，铅芯断了三次。削完他说：“要不你试试把innodb_stats_persistent关了？”我没试。削铅笔的手势很稳，但他削的是圆珠笔芯——办公室早就没铅笔了，只剩一堆印着不同厂商logo的塑料杆子。

　　所以别跟我谈什么“稳定高效之路”，路是拿人趟出来的，不是画在PPT里的。有些坑填了也白填，比如那个跨表JOIN时隐式类型转换导致索引失效的case，改完之后，另一个关联表里新加的json字段又让优化器彻底失明。有些坑根本不用填，比如现在主库的max_connections设的是3000，但实际峰值从来没超过217，可没人敢调，因为上一个敢调的人——是去年离职的王磊，他走的时候硬盘没交还，格式化前最后一张截图是performance_schema.threads表里三百一十二个sleeping状态的连接，全部来自同一个中间件IP段。我敢打包票他当时没删库，但他确实把所有建表语句里的ENGINE=InnoDB手动改成ENGINE=MyISAM，改完才提交的MR，没人review出来。这不是漏洞，这是仪式。

　　我现在工位右上角贴着一张便签，蓝字写着：“如果explain显示type=ALL，先查WHERE，再查COLLATION，最后去翻对方微信头像有没有换过。”这话是隔壁组那个天天穿同一件灰色卫衣的实习生写的，他来了才两个月，但已经帮我们抓出四次排序丢失问题。至于我？今早收到备案中心的短信，说“您的主体信息存在疑似重复填报”，我还没点开链接。外卖骑手刚到楼下，电梯停在十五层不动了，喇叭里传来断续的语音：“请稍候……当前……载重……超限……”

（编辑：站长网）

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