数据库CPU持续飙高怎么办：从慢SQL到索引失效的系统治理方案

问题现象：数据库扩容后仍然很快到达瓶颈

CPU 飙高通常不是单一 SQL 的问题，也可能是大量小查询、连接风暴、排序聚合、隐式类型转换或统计信息失真。先区分计算压力与等待压力：CPU 使用率高但磁盘等待低，常见于扫描、排序和表达式计算；连接数高而吞吐没有增长，可能是应用重试或连接池配置不当。

用执行计划定位真正的成本

分析慢 SQL 时要同时查看预估行数、实际行数、扫描方式、回表次数、排序和临时表。索引存在不代表会被使用，函数包裹字段、类型不一致、前导模糊匹配和选择性过低都会导致索引失效。若预估与实际差异巨大，应检查统计信息和数据分布，而不是继续盲目增加索引。

索引设计围绕访问模式

联合索引的顺序应根据过滤、排序和覆盖需求决定。高频查询可以使用覆盖索引减少回表，但索引过多会增加写入、存储和维护成本。对于深分页，避免不断增大的偏移量，可改用上一页最后一个排序键继续查询。大范围报表不要与在线交易争抢资源，可通过只读副本、离线任务或预聚合处理。

控制连接与突发流量

应用连接池总量必须小于数据库可承受连接数，并为多个实例预留余量。连接数并非越大吞吐越高，过多并发会增加上下文切换和锁竞争。热点接口应配合缓存、请求合并或限流，避免数据库承担全部尖峰。

验证与防复发

优化前后比较逻辑读、扫描行数、执行时间、锁等待和业务吞吐。新索引上线要观察写入延迟和空间增长，确认没有以读优化换来更严重的写问题。问：慢 SQL 阈值设多少合适？答：应按业务延迟预算和调用频次确定，高频的几十毫秒查询也可能比偶发秒级查询消耗更多资源。