半夜三点，手机震了。监控大屏上，生产库的QPS曲线像被砍了一刀，直线坠落。接电话的手还在抖，但脑子已经清醒了——这活儿不是头一回干了。干数据库运维这些年，最深的体会就是：故障处理这技术，平时看着不起眼，真出事的时候，它就是保命的家伙。今天不聊虚的，就把这些年踩坑踩出来的五大核心策略，一条条掰开揉碎了说。
第一个策略，叫“冷启动”。听起来不酷，但这是保底功夫。故障一发生，人容易慌，一慌就乱操作，越操作越乱。我见过太多新手，一看到主库挂了，第一反应就是重启，结果把还在运行的从库也带崩了。正确的做法是：先定三件事——故障影响范围有多大，数据损坏到什么程度，能不能用只读方式先顶上去。这三件事搞清楚了，再动手。记住，数据库故障处理的黄金法则不是“快”，是“稳”。你手抖一下，可能就是几千万条数据的代价。
第二个策略，是“留后手”。说白了，就是备份恢复的颗粒度要细。很多人觉得，我每天全备一次，够了吧？不够。全备完了还有binlog，binlog能精确到秒级恢复。但真正的高手，会提前把binlog的保留时间拉长，同时做好增量备份和归档日志的分离。我有个同事，他们公司就是这样干的，某次误删了一张核心业务表，愣是靠binlog把数据恢复到了误删前五秒的状态，业务几乎无感知。这招叫“时间旅行”，但前提是你得有“时光机”的零件。
第三个策略，得说说“分库分表”这事了。很多团队把分库分表当成性能优化的手段，但在故障处理上，它其实是天然的安全隔离带。你想想，如果所有业务都挤在一个库里，一个慢查询就能把全库拖死。但分了库之后，一个分片挂了，其他分片还能正常跑。前阵子有个客户，他们的订单库分成了16个分片，其中一个分片的磁盘满了，结果只是那个分片的读写失败，其他15个分片照常服务，线上业务只掉了不到5%的容量。这策略的精髓在于：别把鸡蛋放一个篮子里，也别把所有的雷埋在一个坑里。
第四个策略，是“限流降级”的配合。数据库扛不住的时候，不是硬扛，而是要学会“认怂”。限流不是丢数据，而是把压力挡在外面，保住核心链路。比如，你把写请求限流到只允许核心交易通过，把非核心的日志写入直接降级到消息队列里异步处理。这样，数据库的负载降下来了，核心业务反而稳住了。这个策略最考验的是业务梳理能力——你得提前知道哪些是核心，哪些可以牺牲。别等到故障了才去翻代码，那会儿你连翻代码的心情都没有。
第五个策略，是“复盘机制”。这可能是最容易被忽略，但也是最能提升团队战斗力的。每次故障处理完，别急着庆祝，拉上所有相关的人，把时间线捋一遍：几点几分发生了什么，谁做了什么操作，哪一步判断失误了，哪一步本来可以更快。我见过最牛的团队，他们每次复盘都录音，然后逐句分析，连“当时为什么犹豫了三秒”这种细节都不放过。这样复盘个三五次，团队的整体反应速度能提升一倍。
说回开头那个半夜三点的电话。那次故障查出来，是某个开发上线了一个没加索引的查询，把整个主库的CPU打满了。按上面五个策略，先冷启动稳住局面，再用binlog确保数据不丢，然后限流保住核心业务，复盘发现是规范问题，补上了索引审查的流程。整个过程不到四十分钟，业务影响降到了最低。
数据库故障处理这事儿，说到底是门手艺活。手艺活讲究的是熟能生巧，但更讲究的是提前把招数都想好。五大策略不是孤立的，它们是环环相扣的——冷启动是心态，留后手是底气，分库分表是架构，限流降级是战术，复盘机制是进化。把这五样都装进兜里，再遇到半夜三点的电话，你也能心不慌、手不抖，稳稳当当地把活儿干完。毕竟，数据库这行当，真正的功夫都在故障之外。
