半夜两点，手机震了。业务方在群里说订单表查询特别慢，用户下单转圈转了一分钟。我爬起来连上VPN，看了一眼慢查询日志，果然，那个跑了半年的SQL，执行计划又变了。这事干久了你就明白，数据库运维优化不是拿着工具扫一遍，写几篇报告就完事的事。它更像是在高速上边开车边换轮胎，既要保持车速，还得保证别翻车。今天我就把这些年踩过的坑、趟出来的路，跟你掏心窝子聊聊。
先说最容易被忽视的“索引失效”问题。很多运维兄弟一遇到慢查询，第一反应就是加索引，但其实百分之八十的索引问题不是缺索引，而是索引建了没用上。比如你在where条件里对索引列做了函数运算，或者用了隐式类型转换，数据库优化器直接放弃索引，走全表扫描。我见过最离谱的一次，某系统有个用户表，明明在手机号字段上建了唯一索引，结果因为代码里传参是字符串，表里字段是int，MySQL每次查询都把所有行转成字符串再比较，两千万行的表，查询耗时从几十毫秒飙到三秒多。这种问题不靠看执行计划根本发现不了，所以我的习惯是，任何线上慢查询，第一件事不是改代码，而是先抓一条真实SQL，执行EXPLAIN，看type列是不是从ref变成了ALL，看possiblekeys和key是否一致。如果key是NULL，那索引绝对没走对。
再聊聊连接池和并发控制。很多团队觉得数据库慢是数据库的事，其实大部分时候是应用层把数据库给“挤死”的。有个典型场景，业务高峰期，应用服务开了两百个线程，每个线程都从连接池拿连接，连接池最大设了一百，结果剩下的线程全在排队等连接，等待时间一长，前端就报超时。这时候你去数据库看，CPU才用了百分之二十，慢查询也没几条，但业务就是卡死。问题不在数据库，在于连接池参数没调好。我一般建议，连接池最大连接数不要超过数据库实例CPU核数的两倍，最小空闲连接要跟业务波动匹配，避免频繁创建销毁连接。另外，连接池的获取连接超时时间一定要设置，别让线程无限等下去，否则一旦连接池打满，整个应用就陷入死锁式的等待，重启都救不回来。
说一个很实战的案例。之前有个电商平台，大促前一周发现订单表的写入延迟越来越高，从平均十毫秒涨到两百毫秒。排查了一圈，发现是binlog同步到从库的延迟越来越大，主库写入一快，从库就追不上。当时很多人建议加从库数量，或者升级硬件，但我看了下主库的写入模式，发现业务有个定时任务，每五分钟批量更新一次所有未发货订单的“更新时间”，一次更新几十万行。这个操作不仅会产生大量binlog，还会因为行锁竞争拖慢正常交易写入。后来我们把这个定时任务改成只更新当天的订单，或者按订单创建时间分片更新，每次只动几千行，主库压力瞬间降下来，从库延迟也消失了。这个事说明，数据库优化很多时候要往上游看，看应用在干什么，而不是单纯在数据库里折腾参数。
还有个大坑，就是慢查询日志和高频访问热数据的矛盾。很多系统都有个特点，百分之二十的数据贡献了百分之八十的访问，这些热点数据如果每次都要从磁盘读，那性能肯定上不去。我见过一个系统，每天凌晨定时任务把全量商品信息加载到Redis，但白天业务查询有百分之三十是查不存在的商品，这些查询直接穿透到数据库，导致MySQL压力巨大。后来我们加了一层布隆过滤器，把不存在的商品ID提前过滤掉，数据库的无效查询减少了百分之八十。再加上对热点商品做了本地缓存，二级缓存，命中率从百分之五十提升到百分之九十五。这事给我的启发是，数据库运维优化不能只看数据库本身，缓存策略、数据访问模式，这些都属于优化范畴。
分区表和归档策略也值得好好聊。很多业务表，比如流水表、日志表，数据量涨得飞快，一张表几个亿行，索引再建得好，性能也会慢慢劣化。这时候就要考虑分区。我们之前有个支付流水表，一个月涨两千万行，查询经常要跨好几个月，慢得要命。后来按月做RANGE分区，查询条件带上月份，数据库自动走分区裁剪，只扫对应分区的数据，查询时间从五秒降到两百毫秒。同时，三个月前的数据自动归档到历史库，线上表只保留最近三个月。这个操作不仅让查询变快，备份恢复的时间也大大缩短。以前全量备份要三个小时，现在四十分钟搞定。运维工作最怕的就是数据无限膨胀，你得提前设好门槛，而不是等到卡死了再想办法。
参数调优这块，很多人喜欢照搬网上推荐的模板，什么innodbbufferpoolsize设成物理内存的百分之七十，什么maxconnections设成五千。但实际环境千差万别，盲目套模板反而会出事。我见过一个系统，服务器内存只有16G，结果配置文件里innodbbufferpoolsize设了12G，加上其他缓存，操作系统内存直接爆掉，开始用swap，数据库性能反而下降。后来我们把buffer pool降到8G，给操作系统和文件系统缓存留出足够空间，整体性能反而提升了不少。参数调优的核心逻辑是，先搞清楚你的瓶颈在哪个环节。如果是读多写少，buffer pool大点没错；如果是写多，就要关注redo log的大小和刷盘策略。如果是并发高，就要看锁等待和事务隔离级别。没有万能参数，只有对症下药。
稳定性这块，我特别想强调监控和告警的“提前量”。很多团队监控做了，但告警阈值设得不合理，要么天天报警把人吵麻了，要么一出事就是大事。我的经验是，告警要分级别，CPU和内存这种基础指标，阈值设得宽一点，别没事打扰人。但像慢查询数量突增、复制延迟超过十秒、连接数使用率超过百分之八十，这些必须第一时间通知到人。另外，监控不能只看平均值，要看P99和P95。平均值好看，但P99可能已经超时了。之前有个系统，平均查询耗时八十毫秒，看着很健康，结果P99是两秒多，业务反馈就是时快时慢。后来把P99纳入核心监控指标，才发现是有个特定类型的SQL在特定数据分布下会走错执行计划，问题才暴露出来。数据库运维的稳定性，靠的不是祈祷不出事，而是把出事前的信号都接住。
说一句掏心窝子的话。数据库运维优化这件事，永远没有一劳永逸的解决方案。业务在变，数据量在变，访问模式也在变，今天调好的参数，明天可能就不适用了。我每次上线前做变更，都会留一个回滚方案，每次优化完，都会记录前后对比数据和实施过程。这不是怕背锅，而是对生产环境保持敬畏。性能是跑出来的，稳定是守出来的，两者不是对立面，而是同一枚硬币的两面。你多花心思在索引设计、SQL审查、连接池规划、数据生命周期管理上，性能自然就上去了，稳定性也顺带保住了。说到底，数据库运维优化，就是一场跟数据膨胀和业务变化的持久战，你得不停地调整姿势，找到那个平衡点。每次解决完一个线上问题，别急着庆祝，多想想下一次它会在哪里冒头。
