宝塔默认关闭MySQL慢查询日志，需手动开启slow_query_log=ON并设置long_query_time（生产建议1秒），重启MySQL后日志路径为/www/server/data/mysql-slow.log；Query_time不包含锁等待等耗时，应结合Lock_time、Rows_examined及SHOW PROCESSLIST分析；日志为空需检查磁盘、权限与错误日志；EXPLAIN中type=ALL、key=NULL、Using filesort或Using temporary是性能瓶颈关键指标。
慢查询日志没开启，查不到问题SQL
宝塔默认关闭 MySQL 慢查询日志，不手动开，slow_query_log 就一直是 OFF，你再怎么刷页面都看不到慢 SQL。
实操建议：
- 进宝塔 → 数据库 → 选择对应 MySQL 实例 → 点「配置修改」→ 找到
slow_query_log = OFF，改成ON - 同时确认
long_query_time值，生产环境建议设为1（秒），太低会写爆磁盘；开发可设0.1捕获更多可疑语句 - 必须重启 MySQL 生效：在宝塔里点「重启」，或执行
systemctl restart mysqld - 日志路径通常为
/www/server/data/mysql-slow.log，权限要确保 MySQL 进程能写入（常见坑：日志目录属主不是mysql）
日志里全是“Query_time: 0.000xxx”，实际却卡
这是 MySQL 5.7+ 的常见现象：如果 SQL 走了锁等待、IO 等待或网络延迟，Query_time 只计执行时间，不包含排队和等待耗时，看起来快，但用户感知明显卡顿。
实操建议：
- 别只盯
Query_time，重点看Lock_time和Rows_examined—— 锁太久或扫太多行，基本就是问题源头 - 搭配
SHOW PROCESSLIST实时抓活的长事务：SELECT * FROM information_schema.PROCESSLIST WHERE TIME > 60 - 检查是否用了
SELECT *或未加WHERE条件的更新/删除，这类语句在慢日志里可能Query_time很小，但Rows_examined高达几万
开了慢日志但日志文件空，或者只写了几条就停了
常见原因是磁盘满、权限不足，或 MySQL 自动关闭了日志（比如检测到写失败后静默降级）。
实操建议：
- 先用
ls -lh /www/server/data/mysql-slow.log看文件是否存在、大小是否为 0 - 查 MySQL 错误日志：
tail -n 50 /www/server/data/*.err，搜关键词slow log或Could not write - 确认磁盘空间：
df -h /www，尤其注意/www/server/data所在分区 - 检查日志目录权限：
ls -ld /www/server/data，确保属主是mysql:mysql；如果不是，运行chown mysql:mysql /www/server/data
定位到慢 SQL 后，EXPLAIN 结果看不懂关键字段
EXPLAIN 输出里 type 是 ALL、rows 过大、key 为 NULL，基本等于没走索引。但新手常忽略 Extra 里的 Using filesort 或 Using temporary —— 这俩才是真正拖垮性能的隐形杀手。
实操建议：
-
type = ALL或index：说明全表扫描，优先加复合索引，顺序按WHERE条件列 +ORDER BY列排列 -
Extra出现Using filesort：避免在ORDER BY字段上用函数，如ORDER BY DATE(created_at)；改用范围查询或冗余排序字段 -
Extra出现Using temporary：通常是GROUP BY或DISTINCT配合非索引字段，考虑加覆盖索引，或拆成两步查 - 别信
rows估算值，用SELECT COUNT(*)对比真实数据量，偏差大说明统计信息过期，运行ANALYZE TABLE table_name
慢查询不是单点问题，而是索引设计、查询写法、服务器配置、甚至应用层重试逻辑共同作用的结果。最常被忽略的是：没确认慢 SQL 是否真被业务代码调用，还是测试残留 SQL 在后台轮询。先确认调用链，再优化，否则容易白忙。
