宝塔面板默认未开启MySQL慢查询日志，需在面板数据库配置中添加slow_query_log=ON等参数；可用mysqldumpslow分析日志，结合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` <p>注意三个关键数字：<code>Count</code>（执行次数）、<code>Time=3.84s (161s)</code>（单次均值和总耗时）、<code>Rows=1245.0</code>（扫描行数）。重点盯那些 <code>Count</code> 高 + <code>Rows</code> 远大于返回结果数的语句——这说明没走索引，全表扫描了。</p>
- 若
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` <p>重点关注三列：<code>type</code>、<code>key</code>、<code>rows</code>：</p>
-
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 ，单独给 <code>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 强制，但属于兜底手段，应优先检查数据质量与查询逻辑是否合理。
