数据库降级实战：8年优化师揭秘教科书外的查询熔断术

　　一三年那会儿，我跟老陈蹲在科苑北区那间朝北的屋子里改SQL，窗户缝漏风，风扇嗡嗡响得像拖拉机挂二挡。他叼着烟敲回车，我盯着那台冠捷显示器——牌子？记不清了，反正屏幕右下角有个掉漆的“AOC”痕。我们俩刚给电商导出系统加完“查询超时=30秒”的硬开关，沾沾自喜，觉得这就是熔断：查不动就报错，人别等。可用户等的是订单状态，不是错误码。那天下午三点十七分，客服电话炸了，后台慢查询日志里全是JOIN三张表再ORDER BY时间戳的语句，没索引，也没hint。我原以为加个超时就行，结果它真把整个导出队列卡死了——连带下游的库存扣减都悬在半空。老陈把烟头摁灭，说：“下次别只掐脖子，得先拆肋骨。”

　　一七年那会儿已经上云了。阿里云RDS开了读写分离，我亲手配的权重路由，主库只扛写，从库分四路接读。当时特别信“自动熔断”，点开控制台那个“慢查询自动限流”开关，绿灯亮得挺精神。可十一期间大促，流量一涌进来，从库CPU全飙到95%，监控图跟心电图似的。运维喊我去看，我第一反应是调高连接池、扩容只读实例。搞了一夜，第二天早上才看见——原来某条被缓存穿透的搜索语句，在从库上走了全表扫描，而主库根本没这条语句的慢日志，因为它压根没进主库。我漏判了读写路径分裂后的“查询漂移”。那会儿没人提“降级面”，我们只会降“服务”，不会降“查询”。李薇——现在早转去做数据产品了——当时在我工位后边泡枸杞茶，看我反复重启Proxy，她说：“你熔的是链路，不是逻辑。”我没搭理。她后来辞职前留了张便签，字歪：“熔断器不该装在数据库门口，得嵌进SQL里。”

　　前不久，二二年，一个深夜告警：核心商品页加载超时。我直接SSH进数据库，show processlist扫了一眼，发现三十多个线程卡在同一条SELECT上，WHERE条件里有个IN（472个SKU ID）。查执行计划，走的是索引合并，但实际IO暴涨。我习惯性想加hint force index，手指停住了。打开应用层代码——发现这接口居然还挂着十年前写的“分页查询总条数COUNT()”，而页面根本不需要总数。我删了那行COUNT，响应从6.2秒干到187毫秒。可问题不在这里。真正让我后背发凉的是：我们团队新来的应届生小孙，翻出埋了八年的日志埋点，说“这接口三个月前就开始悄悄跳过COUNT了，只是监控没配阈值，所以没人知道”。原来它早就自己降级了，静默地、错误地，把count=0当正常返回传给前端。我原以为熔断得靠人按开关，结果发现最野的降级，是业务自己长出来的退化本能。

　　对了，说到小孙……他上个月问我，能不能把历史慢查询日志对接到内部LLM做归因。我说试试。昨天他发来截图，模型标红了三处，其中一处写着：“WHERE create_time > '2012-01-01' —— 永远命中全索引，建议用范围分区替代。”我盯着那行字看了五分钟。一三年那会儿，我们连MySQL分区都懒得开，嫌麻烦；一七年觉得上TIDB就能解决一切；现在反而又回头去算create_time的散列偏移量……真拧巴。

　　还有个事忘了说：前两天整理旧硬盘，在“2014_备份”文件夹里翻出一个叫“query_kill_rules_v2.1.xlsx”的表格。里面密密麻麻列了237条规则，比如“含SUBSTRING_INDEX且嵌套三层以上，kill；UNION ALL超过两段，kill；使用FIND_IN_SET，立刻kill”。最后备注栏写：“已验证有效，适用于所有主从架构。”我笑出声。去年帮朋友公司救急，他们库表命名全用拼音缩写加下划线，我拿这套规则跑，杀掉了73%的活跃查询——包括一条正在跑的财务月结JOB。我走错的那一步，就是把它当普适律写了进去。规则没毛病，可我把“场景”和“语法”混一块儿了。那表格我现在删了，但本地还留着个txt，标题是“慎用”，里头只有一行：“先看它查什么，再看它怎么查。”

　　赵磊你还记得吗？当年跟我们抢同一个SAAS客户，他做的站全靠采集，一天爬五十万条比价数据，MySQL配的是双主环形复制。有次他服务器崩了，自己扛着主机箱打车来我们办公室借备份——硬盘接口不匹配，硬是拿胶布缠着接上SATA线。他一边弄一边说：“数据库不死，我的站就不死。”三年后他卖站，买方审计第一条就砍掉所有“实时比价查询模块”，说“不准查，不准推，不准算”。现在听说他在做政务数据脱敏中间件，大概率不碰查询熔断了。

文章配图，仅供参考

　　现在的做法？没有标准动作。我让小孙写了三个脚本：一个扫执行计划里有没有全表扫描+高IO；一个抓应用层SQL拼接里的字符串拼凑痕迹；还有一个……算了，不说也罢。反正我再也不敢定一套通用规则。现在这套我也拿不准还能干几年。

（编辑：均轻资讯网）

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