上周五晚上十一点，我正在厨房煮宵夜，手机连着震了三次。监控平台推送告警，核心库的活跃会话数飙到了三百多。那套系统平时也就七八十个并发，这个数字意味着要么业务出了异常，要么SQL写崩了。我放下筷子，打开电脑连上VPN。这种场景干运维的都不陌生，数据库出问题从来不看时间，它只挑你最不想干活的时候发作。但恰恰是这种时刻，才最能检验日常积累的功夫——监控指标有没有配全，告警阈值合不合理，应急预案是不是真的能跑通。
先说故障预警这块。很多人以为预警就是装个监控软件，画几个折线图，设几个阈值就完事。真到了生产环境，你会发现事情远没这么简单。前年我们接手过一套Oracle RAC，客户说监控报警太频繁，半夜老是被吵醒。排查下来发现，告警阈值设得太低，系统正常波动都能触发。但调高阈值之后，又有两次真正的故障没报出来——慢查询堆积把连接池打满了，监控上硬是没显示。教训很直接：预警系统不是设了就行，得根据业务周期、历史基线、数据增长趋势反复校准。比如我们后来做了一套动态基线，把周一到周五早高峰和周末凌晨分开计算，正常波动不报警，真出问题三分钟内必响。
再说说故障定位的速度。数据库出问题，最怕的是大家围着机器转圈，谁都不知道该从哪下手。我见过太多次故障演变成事故，就是因为排查路径错了。比如有一次MySQL主从延迟突然拉大，开发说是网络问题，网络组说是磁盘IO问题，DBA说是大事务问题，三方扯了四十分钟，发现是备份任务把从库的IO全占了。如果一开始就按“先看监控曲线、再查会话状态、看系统资源”的固定顺序排查，十分钟内就能定位。所以我们后来规定，任何数据库故障，第一件事是看监控大屏上的四个指标：活跃会话数、锁等待数、磁盘IO延迟、网络重传率。这四个指标能帮你快速缩小范围，剩下的再针对性深入。
预警和定位都做扎实了，接下来才是性能优化。很多人一提性能优化就想到加索引、改SQL，这没错，但顺序得讲究。有一次我们优化一个订单查询接口，接口平均耗时两秒多，开发上来就说是SQL慢，要加索引。我们一看执行计划，明明走了索引，但表数据量一千万，查询条件里有个范围筛选，索引选择性太差，效果有限。后来我们换了个思路，把历史订单按月分表，查询只扫当月数据，接口耗时直接降到两百毫秒。这个案例说明，性能优化第一件事不是动SQL，而是看数据分布和访问模式。数据量大的先考虑分区或分表，数据量小的先看索引是否冗余，然后才是SQL改写和参数调优。
参数调优这块，最容易被忽视的就是缓冲池和连接池的配比。很多DBA喜欢照搬网上推荐的参数模板，但生产环境的内存、磁盘、并发量都不一样，照搬容易出问题。比如InnoDB的缓冲池，设得太大，留给操作系统的内存不够，触发SWAP反而更慢；设得太小，热点数据频繁淘汰，磁盘IO直线上升。我们一般是先压测，用工具模拟业务高峰，观察命中率和IO延迟的拐点，再反向推算合适的参数值。连接池也同理，不是越大越好，连接数超过某个量级，上下文切换的开销会吞掉并发收益。这个平衡点，只能靠实际负载数据来定。
还有一类问题，平时不怎么显眼，但一到关键时刻就掉链子——那就是慢查询日志和锁等待分析。我们有个习惯，每周例行检查慢查询日志，把执行时间超过一秒的SQL全部拉出来过一遍。不是所有慢查询都要立刻优化，有些是业务特性决定的，比如报表统计的聚合查询，跑个两三秒正常。但要是发现某条SQL的执行时间在逐步变长，那就得警惕了——很可能是数据量增长导致执行计划退化。这时候就得重新分析统计信息，或者调整索引策略。锁等待更隐蔽，有一次我们发现应用偶尔报超时，但监控上看不出明显异常，后来查了锁等待记录，才发现是批量更新任务和在线交易抢同一批记录的行锁。解决方案也简单，把批量任务改到凌晨低峰期跑，问题就消失了。
说完优化，还得提一嘴容量规划。数据库运维不能只看当下，得往前看半年一年。我们每个月都会做数据增长趋势分析，看看磁盘空间还能撑多久，计算资源是否够用。有一次我们预估半年后磁盘会满，提前三个月申请了新存储，结果业务发展比预期快，两个月就把空间吃完了。幸好提前做了扩容，不然后果不堪设想。容量规划的关键在于，不能只看总量，还得看热点分区的分布。有时候总量够，但某个分区增长特别快，比如订单表按月份分区，双十一那月的分区提前爆掉，其他分区还很空闲。这种不平衡，也得提前做调整。
回到开头那个深夜告警。那晚我连上环境，先看监控曲线，发现活跃会话数是一条陡峭的直线，不是缓慢爬升。这个特征基本排除了业务自然增长的可能，更像是某个定时任务跑起来的SQL把表锁住了。我查了锁等待记录，果然，一个凌晨的统计任务和另一个数据清理任务在抢同一张表的行锁。处理办法也简单，把两个任务的调度时间错开十五分钟，问题就解决了。从收到告警到处理完毕，前后不到二十分钟。事后复盘，这套系统的监控指标和预警阈值起了大作用，但更关键的是，我们平时把各种故障场景都演练过，所以看到症状就能快速判断出病因。
数据库运维这行，说到底是门手艺活。预警、定位、优化、规划，每一步都得靠真实环境里的摸爬滚打才能练出来。工具和平台能帮你省力，但替代不了经验判断。就像老中医把脉，机器能测出心率血压，但辨证开方还得靠人。我们做的这些规范和流程，本质上就是把经验固化下来，让团队里每个成员都能在紧急时刻做出正确判断。从故障预警到性能优化，这条路没有终点，业务在变，数据在涨，新的问题会不断冒出来。但只要你把每个环节都做扎实了，遇到问题就能心里不慌，手上有招。
