凌晨两点十七分，报警电话把我从睡梦里拽出来。值班同事的声音有点发紧：“订单库CPU百分之百了，写入全卡住，前端已经报错。”我一边套外套一边让他把慢查询日志和监控面板截图发过来。说实话，干这行最怕半夜来电话，但既然来了，就得在最短时间内把问题摁住。数据库故障这种事，拖一分钟，业务损失就是实实在的真金白银。
我先扫了一眼监控大屏上的曲线，CPU从一点五十分开始直线拉升，之前一直平稳。这说明不是突发流量，而是某个操作在某个时间点突然失控。再看慢查询，果然，一条update语句的扫描行数从几千跳到了几百万。这条语句平时跑得挺快，怎么突然就慢了呢？我让同事把这条SQL的执行计划拉出来，重点看索引使用情况。结果发现，它走的索引没问题，但过滤条件里有个字段，突然出现了大量重复值。
问题开始有眉目了。这个字段是用户类型，原本只有几个固定值，索引区分度很高。但那天晚上，上游数据同步任务出了岔子，把一批脏数据灌了进来，用户类型字段被写成了同一个值。这下好了，索引区分度瞬间崩塌，优化器一看，走索引还不如全表扫描快，干脆放弃索引，直接扫全表。几百万行的表，每秒几十万次的全表扫描，CPU不爆才怪。
定位到这一步，其实只用了不到三分钟。但真正的难点在于，怎么在不影响业务的情况下把问题解决掉。直接删脏数据？不行，那是上游的数据，删了还得找他们扯皮。改SQL加提示词强制走索引？治标不治本，脏数据还在，下次还会复发。最稳妥的办法，是先把业务流量切到只读库，让主库喘口气，然后和上游确认脏数据的清洗方案。
我让同事把读写分离的开关打开，写入流量暂时切到备用主库，查询流量继续走只读节点。切换过程大概用了四十秒，前端报错立刻消失。但我知道，这只是缓兵之计，根因不解决，备用主库迟早也会被拖垮。趁着业务恢复的窗口期，我直接拉上上游负责人，让他们定位数据同步任务的问题，同时写了个一次性脚本，把脏数据逐条修正回正常值。
整个过程从接到报警到业务完全恢复，前后不到五分钟。但说实话，这五分钟里每一步都踩在刀尖上。切换流量的时候，备用主库的负载也在往上走，如果那个时刻备用库也扛不住，我们就得考虑更极端的降级方案。好在平时演练做得多，切换流程都是验证过的，关键时刻没掉链子。
事后复盘，这个故障其实暴露了两个问题。第一，上游数据同步任务缺少字段级别的校验，脏数据就这么大摇大摆进了核心表。第二，我们监控体系里，对索引区分度的变化没有预警，否则在脏数据灌入的那一刻就能发现苗头，根本不用等到CPU爆掉才被动响应。这两个问题，一个在流程，一个在技术，缺一不可。
后来我把这次案例写进了团队的知识库，还专门做了一次分享。有个刚入职的同事问我，说“哥，你这五分钟里最关键的判断是什么？”我想了想，告诉他说，最关键的不是你多懂数据库原理，而是你能不能快速分清“先止血”和“找病根”这两件事的优先级。很多新手一上来就想着揪出根因，结果业务一直在报错，压力越来越大，反而乱了阵脚。正确的做法是先恢复业务，再慢慢挖根因。
数据库故障处理，说到底就是一场和时间赛跑的游戏。五分钟后业务恢复了，但真正的战斗才刚刚开始。脏数据清理完，索引区分度恢复正常，CPU曲线回落，监控面板上所有指标都绿了，我这才敢躺回床上。但脑子还在转，想着明天得把上游的校验逻辑加上，把监控的告警阈值调低。干这行就是这样，每一次故障都是一次免费的实战教学，关键是你能不能把教训变成经验，把经验变成机制。
