宝塔数据库CPU飙升排查与优化方法

本文深入解析了宝塔面板环境下MySQL数据库CPU异常飙升的系统性排查与优化路径：从手动安全开启被默认关闭的慢查询日志（强调通过宝塔界面配置而非直接修改my.cnf），到利用mysqldumpslow高效定位高频高耗时SQL；再通过EXPLAIN精准诊断索引失效原因（如全表扫描、索引未命中、函数/隐式转换导致失效），最终指导科学构建等值在前、范围在后的联合索引并验证效果，同时提醒避开锁表风险、警惕数据倾斜等实战陷阱，为运维人员提供了一套即学即用、环环相扣的性能调优闭环方案。

怎么看 MySQL 慢查询日志是否已开启

宝塔面板默认不开启慢查询日志，CPU 占用异常时若直接查 slow_query_log 变量，大概率返回 OFF。先确认状态：

mysql -uroot -p -e "SHOW VARIABLES LIKE 'slow_query_log';"

如果为 OFF，需手动开启——但别急着改配置文件。宝塔的 MySQL 配置由面板接管，直接改 /www/server/mysql/my.cnf 可能被下次重启或面板更新覆盖。

• 进宝塔 → 数据库 → 选择对应 MySQL 实例 → 点「配置修改」→ 在 [mysqld] 区块末尾添加：

slow_query_log = ON<br>slow_query_log_file = /www/server/data/mysql-slow.log<br>long_query_time = 2<br>log_queries_not_using_indexes = OFF

long_query_time = 2 表示记录执行超 2 秒的 SQL；生产环境建议先设为 1 或 0.5，避免漏掉实际拖慢响应的语句；log_queries_not_using_indexes = OFF 别开，否则日志会爆炸式增长，干扰定位真正慢的语句。

如何快速从慢查询日志里抓出高频/高耗时 SQL

日志文件本身是纯文本，但直接 cat 或 vim 查看效率极低。优先用 mysqldumpslow（MySQL 自带工具）做聚合统计：

mysqldumpslow -s t -t 10 /www/server/data/mysql-slow.log

-s t 按总执行时间排序，-t 10 取前 10 条。你会看到类似这样的输出：

Count: 42  Time=3.84s (161s)  Lock=0.00s (0s)  Rows=1245.0 (52290), user[host]@mysql<br>  SELECT * FROM `orders` WHERE `status` = 'pending' AND `created_at` < 'N'

注意三个关键数字：Count（执行次数）、Time=3.84s (161s)（单次均值和总耗时）、Rows=1245.0（扫描行数）。重点盯那些 Count 高 + Rows 远大于返回结果数的语句——这说明没走索引，全表扫描了。

• 若 mysqldumpslow 报错“command not found”，说明 MySQL bin 目录未加入 PATH，可直接用绝对路径：/www/server/mysql/bin/mysqldumpslow
• 日志中出现 # Time: 2024-06-12T08:23:41.123456 后紧跟 SQL，但中间可能夹杂 # User@Host 和 # Query_time 行，别把注释行当 SQL 执行

怎么判断某条 SQL 是否走了索引

拿到可疑 SQL 后，别急着加索引。先用 EXPLAIN 看执行计划：

EXPLAIN SELECT * FROM `orders` WHERE `status` = 'pending' AND `created_at` < '2024-06-01';

重点关注三列：type、key、rows：

• type = ALL：全表扫描，必须优化
• type = index：索引全扫描，比 ALL 好但仍有风险
• key = NULL：明确没走任何索引
• rows 值远大于实际结果数（比如查 10 条却显示 rows=12450）：说明索引失效或没建对

常见失效场景：WHERE 中对字段用了函数（如 DATE(created_at) = '2024-06-01'）、隐式类型转换（status 是 varchar 但传了数字）、LIKE '%xxx' 开头通配。这些情况下即使有索引也用不上。

加索引不是越多越好：哪些字段适合建联合索引

单列索引对多条件查询效果有限。比如上面那个 WHERE status = ? AND created_at < ?，单独给 status 或 created_at 加索引都没用——MySQL 只能选其一，另一个条件仍要过滤。

正确做法是建联合索引，顺序很重要：

• 等值查询字段放前面（如 status），范围查询字段放后面（如 created_at）——因为 B+ 树索引中，范围查询后无法再使用后续字段的索引
• 所以建 INDEX idx_status_created (status, created_at) 有效，反过来建 (created_at, status) 就无效
• 联合索引字段数别超过 3 个，否则写入开销大、缓存命中率低

建完立刻验证：EXPLAIN 再跑一遍，确认 type 变成 range 或 ref，key 显示刚建的索引名，rows 接近实际返回行数。

宝塔里执行 DDL 建索引可以直接在「数据库」→「管理」→「SQL 执行」里粘贴 ALTER TABLE `orders` ADD INDEX idx_status_created (`status`, `created_at`);，但大表加索引会锁表，务必避开业务高峰。

最常被忽略的一点：加完索引不代表万事大吉。有些 SQL 因数据分布倾斜（比如 95% 的订单 status 都是 'pending'），即便走了索引，MySQL 优化器也可能认为全表扫描更快，从而放弃索引——这时得用 FORCE INDEX 强制，但属于兜底手段，应优先检查数据质量与查询逻辑是否合理。

好了，本文到此结束，带大家了解了《宝塔数据库CPU飙升排查与优化方法》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！