秋季数据库巡检别偷懒，这几个坑我真踩过
去年10月中旬的一个凌晨，我被电话叫醒。一台跑了三年的MySQL主库，磁盘IO直接顶到95%，主从延迟从平时的0.5秒飙到47秒。第一反应是慢SQL，翻完日志发现SQL一点没变，倒是机房那边的空调跟着气温降下来调了模式。这事之后我才意识到，换季对数据库来说真不是小事。
温差一大，先扛不住的是硬件
机房空调大多数是按夏季工况调的，入秋以后室外温度降得快，运维如果没及时改设定，机柜进风温度可能从22度慢慢爬到28度以上。这个区间看着不吓人，但机械硬盘的故障率对温度很敏感，业内测试数据是每升高5度，年故障率大概翻一倍。SSD相对皮实，可主控过热一样会降速，表现出来就是写入延迟忽高忽低。
还有个容易被忽略的点：秋季空气干燥，静电风险上来了。我见过一次换内存条的时候没戴防静电手环，插上去直接把一根条子干废了。硬件层面的东西平时不影响业务，一出问题就是整台机器下线。
我自己的秋季检查清单
这几年我固定成一套流程，9月底到10月初做一遍，大概花半天时间，比出事以后熬夜划算得多。
- 看SMART里的重分配扇区数和待定扇区数，这两个数字只要在涨，就别等了，直接申请换盘
- 备份不能只看"成功"日志，挑一个最近的备份在测试库真恢复一次，我自己遇到过备份文件完整但binlog断档的情况
- 检查连接池配置，秋天开始业务量往上走，max_connections和wait_timeout按去年同期峰值再上浮20%
- 把去年同期的订单、日志类冷数据归档到历史库，主库表瘦下来，查询响应能快一大截
- 提前压测一次，别等双十一前一周才发现扩容没做
归档这条我想多说一句。我经手的一个库，订单表堆了两年数据，单表8000多万行，秋天做了一次归档，把一年前的记录挪走，主库表降到2000万行以内，同样的查询从1.8秒降到0.3秒。业务代码一行没改，效果比加索引来得实在。
换季也是业务旺季的起跑线
做电商或者有年度结算的公司，秋天基本是Q4的备战期，双十一、双十二、年底对账全挤在后面两三个月。数据库这时候的定位很尴尬：你想动它，怕出问题；不动它，等到流量上来再改就来不及。
我的做法是错峰。10月中旬之前把该做的变更做完，包括版本升级、参数调整、索引重建，做完留两周观察期。到了11月，只做监控和扩容，不动结构。这个节奏我用了三年，没在旺季翻过车。
监控阈值也得跟着调。夏天流量平稳，CPU超过70%告警没问题；秋天业务爬坡，这个阈值天天响，人反而麻木了。我会临时把阈值提到80%，同时把慢查询的采样频率从5分钟一次改成1分钟一次，宁可多看几条日志，也别漏掉真正的隐患。
说到底，数据库这东西不出问题的时候你感觉不到它，一出问题就是全公司的会。秋天花半天做一次体检，把硬件、备份、容量这三块过一遍，比什么都强。