MySQL慢查询到毫秒响应：20年缓存老兵实战优化

　　跟老板拍桌子那天，空调坏了三台，就剩我工位右后方那台在滴水，嗒、嗒、嗒，打在铁皮接水盘上，像 MySQL 的 slow_log 在刷屏。我说“查一次 1.7 秒的订单聚合，加 Redis 就完事”，他指着 PPT 上“全链路压测达标率 99.8%”说：“你得把这 0.2% 的毛刺，从 SQL 层就焊死。”我点头，转身出门时顺手抄走了茶水间最后一包雀巢速溶——不是饿，是怕待会儿吵到脱水。

　　Lighthouse 跑分截图发到群里没人回。倒不是没看见，是前端老张刚提交了个 webpack 配置，正在群里发语音：“这个 splitChunks……喂？听得到吗？”他声音被掐断在第 1.3 秒，估计是信号切到了地下室电梯井。我截图右下角时间是下午三点零七分，桌面那个没关的录屏软件正悬在右上角，小红点亮着，录制时长：00:47:22。我没关——留着，反正下周要给审计组看“缓存变更可追溯”。

　　先扔结论：慢查询变毫秒，靠的不是缓存多聪明，是优胜劣汰太狠。MySQL 活下来的那条 SQL，它自己就快了；活不下来的，全被 Cache 拦在外面——连执行器都懒得见它。这不是优化，是流放。我原以为得改索引顺序，结果发现 DBA 上个月已经悄悄把 order_by 字段加了覆盖索引，但没通知任何人。我翻 commit 记录，作者是后端老陈，他改完顺手提了个合并请求，勾选“自动合并”，然后点了三次“确认”，再点“合并”，最后又点了一次“刷新页面”——就为了看那个绿色对勾是不是真出来了。这人写注释永远用中文句号，从不加分号，但我敢打包票，他删表前一定先 mysqldump -hlocalhost -u…（后面记不清了，我说不准）。

　　CDN 账单上个月涨了十八万。财务拿Excel来问我：“缓存穿透导致的回源突增，能归到你们成本池吗？”我没接表格，直接翻出上季度 SLO 报告里一行小字：“缓存命中率 ≥98.5%，SLI 基于 LRU 最近一小时统计窗口”。她盯了三秒，叹了口气，把U盘拔了。U盘壳是磨砂黑的，侧面有个划痕，像被钥匙刮过。我们没谈钱的事，只聊了两分钟天气——她老家台风刚过，我家楼顶积水三天没退。这跟我手头那个慢查询没一毛钱关系，但它就在那儿，真实，硌人。

文章配图，仅供参考

　　对面工程师换了一根充电线。白色，Type-C，带编织纹，和他上个月用的那根几乎一样，但插上电脑后系统没弹识别提示。他拔了两次，第三次按住 Shift 键再插，终于亮蓝灯。他松了口气，转头问我：“你那边缓存预热脚本，跑完之后会清掉 old version key 吗？”我说不清——预热脚本是我三年前写的，后来交给运维跑 cron，我只管每月初核对日志里的“cache_preheat_done: true”行数。但上个月有三天没打这个日志。我没报障，因为那三天，线上压根没人投诉加载慢。这事我不敢下结论，只默默把那个 Python 脚本路径发给了DBA小王，他回了个表情包：一只熊猫捂眼。我没再问。

　　KPI 折算最近改成“有效缓存命中超额比例”——也就是比 baseline 多出来的命中次数 / 总请求 × 100%。Baseline 是去年双11峰值，但他们忘了删测试环境的脏数据：我们开发库每天凌晨自动灌一万条 mock 订单，其中九千八百条状态是 ‘canceled’，而这部分也计入“缓存查询总量”。所以哪怕我啥也不干，只要让 cancel 状态也走缓存，KPI 自动飘红。运营部昨天还在邮件里夸“缓存策略显著提升资源复用率”。我删了邮件草稿箱里准备发的澄清，点了发送——附言：“附：mock 数据清洗逻辑已同步至运维 SOP v3.1”，SOP 里其实就一行：“# TODO: 清洗 canceled 订单缓存键（负责人：待定）”。

　　所以你现在问我怎么做的？我只能说：先把那三十条慢 SQL 打印出来贴墙上，然后每天早上来撕一条。撕掉的，要么是加了 cache，要么是前端砍掉了需求，要么是产品自己觉得“好像也没那么急”。剩下没撕的，等下次事故复盘时，看谁先扛不住——不是技术扛不住，是人扛不住。这周我打算撕第七条，编号 SQL-2024-08-23-B，是个带 JSON_CONTAINS 的查询，跑得慢，但客户还没投诉。我先不动它。让它再活三天。就三天。

（编辑：站长网）

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