宝塔面板“慢查询日志”页面为空，根本原因是MySQL慢查询日志未实际启用或日志文件未写入；需确认slow_query_log=ON、log_output=FILE、long_query_time合理，并检查/www/server/data/mysql-slow.log是否存在且持续增长。
慢查询日志必须开启且日志文件可读，否则宝塔面板的“慢查询日志”页面就是空的——这不是功能失效，而是底层没数据。
确认 MySQL 慢查询日志已实际启用并写入文件
宝塔面板的「慢查询日志」页面只是读取 mysql-slow.log 文件内容的前端展示，它不负责生成日志。如果点开页面是空白或提示“暂无数据”，优先排查日志是否真在写入：
- 执行
ls -l /www/server/data/mysql-slow.log，确认文件存在且大小在增长（如 10 分钟内从 0 变成 2KB） - 若文件不存在，检查
slow_query_log是否为ON：mysql -e "SHOW VARIABLES LIKE 'slow_query_log';" - 若值为
OFF，说明面板上点的“开启”没生效——常见原因是 MySQL 配置中log_output被设为NONE，需手动改回FILE - 执行
mysql -e "SHOW VARIABLES LIKE 'long_query_time';"，确认阈值不是 10 或 30 这种明显偏高的值
在宝塔面板中直接查看结构化慢查询记录
该功能依赖于日志文件格式规范，仅适用于标准 MySQL 慢日志格式（非自定义 log_output=TABLE 或 JSON）。它比手动翻文本快得多，但有硬性前提：
- 必须使用宝塔 v7.9.0 及以上版本；旧版即使日志存在，也不会显示「慢查询日志」导航按钮
- 点击数据库 → 设置 → 高级选项卡 → 确保「慢查询日志」开关是绿色开启状态，且「慢查询阈值(秒)」填的是数字（如
1），不能是空或带单位的字符串（如1s） - 每条记录里的「扫描行数」和「返回行数」差距极大（比如扫描 10 万行只返回 1 行），大概率缺索引；「锁定时间」高则说明存在锁竞争
- 面板默认只加载最近 100 条，不支持翻页或按库名筛选——真要查某张表的慢查询，得去文件管理器里搜
/www/server/data/mysql-slow.log
用 tail -f 实时盯住新产生的慢查询
压测、上线后突发卡顿、或想确认某次操作是否触发慢查时，面板的静态列表刷新太慢，tail -f 是唯一可靠手段：
- 先确认日志路径：
mysql -e "SHOW VARIABLES LIKE 'slow_query_log_file';"，输出通常是/www/server/data/mysql-slow.log - 执行
tail -f /www/server/data/mysql-slow.log，新开终端窗口专门跑这个命令 - 注意：如果
tail -f输出为空但已有慢查询发生，说明log_output被设成了TABLE（写入mysql.slow_log表），此时得用SELECT * FROM mysql.slow_log ORDER BY start_time DESC LIMIT 10; - 别在日志滚动时 Ctrl+C 中断——这会丢失缓冲区里还没刷到屏幕的几条，用
Ctrl+Z挂起更安全
为什么开了慢日志却看不到 INSERT/UPDATE 的慢记录？
MySQL 默认只记录 SELECT 类型的慢查询，DML 语句（INSERT、UPDATE、DELETE）是否计入慢日志，取决于 log_slow_admin_statements 和 log_queries_not_using_indexes 这两个变量：
-
log_slow_admin_statements = ON才会让ALTER TABLE、ANALYZE TABLE等管理语句进慢日志 -
log_queries_not_using_indexes = ON会让所有未走索引的查询（包括INSERT ... SELECT、UPDATE带 WHERE 子句）被记录，哪怕执行时间没超long_query_time - 这两个参数在宝塔面板图形界面里不暴露，必须手动编辑
/www/server/mysql/etc/my.cnf，在[mysqld]下添加并重启 MySQL - 特别注意：
log_queries_not_using_indexes在高并发写入场景下可能让日志爆炸，建议只在排查期临时开启
慢查询日志本身不消耗多少资源，但长期开着 log_queries_not_using_indexes 或把 long_query_time 设成 0.1，会导致 I/O 压力陡增——监控不是越细越好，而是刚好够定位问题。
