在宝塔面板中需手动编辑my.cnf配置slow_query_log=1、long_query_time=1和slow_query_log_file为绝对路径，重启mysql服务后生效；重点分析rows_examined远超rows_sent、using filesort及using temporary的sql，并针对性创建覆盖where与order by字段的联合索引。
怎么打开 MySQL 慢查询日志（宝塔面板里）
宝塔默认不开启慢查询日志，得手动配。关键是改 my.cnf 里的两个配置项，不是点点就完事——配错位置或漏重启，日志根本不会写。
-
slow_query_log = 1必须设为1，设成ON或字符串会失效 -
long_query_time = 1建议先设1秒，别一上来就压到0.1，否则日志爆炸、磁盘占满 - 日志路径用绝对路径，比如
slow_query_log_file = /www/server/data/mysql-slow.log，别用相对路径，宝塔下容易找不到 - 改完必须执行
systemctl restart mysqld（或在宝塔「软件商店」里点 MySQL 的重启按钮），只重载配置不生效
怎么看慢查询日志里真正该优化的 SQL
直接 tail -f /www/server/data/mysql-slow.log 看，但别被“执行时间长”骗了——重点不是单次耗时，而是重复出现、没走索引、扫描行数远超返回行数的语句。
- 盯紧
Rows_examined：如果它比Rows_sent大几十倍（比如查 1 条却扫了 5 万行），基本就是全表扫描 - 留意
Using filesort和Using temporary：说明排序/分组没走索引，尤其在ORDER BY或GROUP BY场景下很常见 - 避免被
SELECT *带偏：日志里显示的是原始 SQL，但真正问题常在没加索引的WHERE字段，比如WHERE status = ? AND create_time > ?却只对status建了单列索引
哪些索引能真正提升查询速度（不是乱建）
索引不是越多越好，宝塔服务器内存有限，冗余索引反而拖慢写入、增加 Buffer Pool 压力。优先覆盖高频慢查询的 WHERE + ORDER BY 组合。
- 联合索引顺序很重要：
INDEX (a, b, c)能加速WHERE a=1 AND b=2，但对WHERE b=2无效 -
ORDER BY字段必须放在联合索引**末尾**才可能避免 filesort，比如查询WHERE user_id = 123 ORDER BY created_at DESC，索引应建为INDEX (user_id, created_at) - 别给
TEXT或很长的VARCHAR字段建全文索引以外的索引，B+ 树存不下，MySQL 会静默截断，导致索引失效
为什么开了慢日志，还是看不到某些“明显很慢”的查询
常见原因是查询被缓存了，或者根本没进 MySQL 执行层——比如宝塔里开了 PHP OPcache，或者前端用了 Redis 缓存结果，你以为是 MySQL 慢，其实压根没查库。
- 确认是否真走 MySQL：在慢日志开启状态下，用
SELECT SLEEP(2)测试，如果日志里没这条，说明配置没生效 - 检查
log_queries_not_using_indexes = 1是否开启——它会记录所有没走索引的查询（哪怕执行很快），适合找潜在隐患，但会大幅增加日志量，上线环境慎开 - 注意连接池和连接复用：有些 ORM（如 Laravel 的 Eloquent）会在事务里复用连接，慢查询可能被合并或延迟写入日志，建议配合
SHOW PROCESSLIST实时抓活的慢连接
ls -lh /www/server/data/mysql-slow.log 看大小。
