如何在phpMyAdmin中查看慢查询日志_结合状态变量分析性能瓶颈-phpMyAdmin-PHP中文网

慢查询日志默认未启用，需手动开启并调低long_query_time；日志路径需MySQL用户有写权限；phpMyAdmin仅显示计数器，不提供日志内容查看功能；log_queries_not_using_indexes易污染日志，应慎用；Handler_read_*变量可辅助定位扫描瓶颈。

慢查询日志默认根本没开，`slow_query_log` 是个摆设

phpmyadmin 本身不记录慢查询，它只是个数据库管理界面。真正起作用的是 mysql 服务端的配置。如果你在 phpmyadmin 的「状态」页里看到 slow_queries 值为 0，或者长期不变，大概率是 slow_query_log 根本没启用，或者 long_query_time 设得太高（比如默认 10 秒），导致日常查询全被过滤掉了。

实操建议：

先确认 MySQL 是否允许运行时修改：执行 SELECT @@slow_query_log, @@long_query_time; —— 如果返回 OFF 或 0，说明没开
临时开启（重启前有效）：SET GLOBAL slow_query_log = 'ON'; SET GLOBAL long_query_time = 1;（设成 1 秒更易捕获问题）
永久生效必须改 MySQL 配置文件（my.cnf 或 mysqld.cnf），在 [mysqld] 下加两行：slow_query_log = ON 和 slow_query_log_file = /var/log/mysql/mysql-slow.log
注意路径权限：MySQL 进程用户（如 mysql）必须对日志目录有写权限，否则启动时报错但可能静默失败

phpMyAdmin 里看不到慢日志文件内容，`SHOW VARIABLES LIKE 'slow_query_log_file'` 才是关键

phpMyAdmin 没有内置慢日志查看器。你点「状态」→「监控」看到的 Slow_queries 只是个累计计数器，不是日志本身。真要读日志，得先知道文件在哪。

实操建议：

在 phpMyAdmin 的 SQL 窗口执行：SHOW VARIABLES LIKE 'slow_query_log_file';，拿到实际路径（比如 /var/lib/mysql/hostname-slow.log）
这个路径通常不在 web 可访问目录下，不能直接用浏览器打开；需要登录服务器用 tail -n 50 /path/to/slow.log 查看最新条目
如果返回空值或 NULL，说明 slow_query_log 虽然开了，但日志文件路径未显式指定，MySQL 会按规则自动生成（常落在数据目录下，文件名含主机名），得结合 datadir 变量一起查

`log_queries_not_using_indexes` 会严重污染慢日志，别随便开

这个选项会让所有没走索引的查询都记进慢日志，哪怕执行只花了 0.0001 秒。线上环境一开，日志体积暴增，Slow_queries 计数器瞬间失真，排查真正耗时的查询反而更难。

amphp

使用 AMPHP 框架编写非阻塞异步 PHP 代码，依赖 revolt/event-loop、amphp/amp ^3 及完整 amphp/* 生态（http‑server、http‑client 等）。

下载

实操建议：

仅在本地或压测环境临时开启，用于发现缺失索引的表，用完立刻关：SET GLOBAL log_queries_not_using_indexes = 'OFF';
生产环境排查性能问题，优先调低 long_query_time（比如 0.5），再配合 pt-query-digest 分析日志，比盲目开这个参数靠谱得多
注意：即使 log_queries_not_using_indexes = OFF，只要查询超时长，依然会被记录 —— 它和慢查询逻辑是正交的

状态变量 `Handler_read_*` 比慢日志更能定位扫描瓶颈

有些查询没进慢日志（比如 long_query_time=1 但实际 0.8 秒），却拖垮了整体响应。这时看 Handler_read_rnd_next 或 Handler_read_full_join 这类状态变量，比盯着日志更早发现问题。

实操建议：

在 phpMyAdmin「状态」页 → 「监控」→ 「刷新」后观察变化：执行一个可疑查询前后，对比 Handler_read_rnd_next 是否猛增 —— 增幅大说明大量随机 IO（典型如 filesort 或临时表回表）
Handler_read_first 高意味着频繁全索引扫描；Handler_read_key 低而 Handler_read_next 高，可能是索引选择性差，走了范围扫描但返回太多行
这些变量是会话级累加的，想精准归因，最好在干净连接里执行单条语句后立刻查：SHOW SESSION STATUS LIKE 'Handler%';

慢查询日志和状态变量是两套互补线索：日志告诉你“哪条语句慢”，状态变量告诉你“为什么慢”。很多人卡在第一步——连日志都没开，或者开了但路径权限不对、参数设得太高，结果以为没瓶颈，其实是没看见。