phpMyAdmin 5.1 不显示真实SQL执行耗时，界面底部“SQL查询时间”仅为HTTP请求周期耗时，无参考价值；需通过FLUSH STATUS+SHOW STATUS查Handler指标，或启用慢查询日志配合mysqldumpslow分析。
phpMyAdmin 5.1 本身不显示 SQL 执行耗时
你执行一条 SELECT 或 UPDATE，phpMyAdmin 5.1 只返回结果集或影响行数，**不会在界面任何位置显示“Execution time: 0.042s”这类耗时数据**。这不是配置问题，是它压根没实现这个功能——不像 MySQL 命令行的 \timing 或某些客户端（如 DBeaver）那样自动计时。
想看真实耗时，必须用 MySQL 原生命令配合
phpMyAdmin 是个 Web 前端，底层仍走 MySQL 协议。要拿到执行耗时，得靠 MySQL 自身的状态变量和计时机制：
- 执行前先运行
FLUSH STATUS，清空会话级统计 - 再执行你的目标 SQL（比如
SELECT COUNT(*) FROM orders WHERE created_at > '2024-01-01'） - 立刻执行
SHOW STATUS LIKE 'Handler_%'，重点关注：Handler_read_next（索引遍历行数）、Handler_read_rnd（回表次数），数值越小通常意味着 I/O 越少、实际耗时越低 - 如果想粗略比对两次查询快慢，可额外记下
SELECT NOW(6)执行前后的时间差（微秒精度），但注意这包含网络往返和 phpMyAdmin 渲染开销，不是纯 SQL 执行时间
别信“SQL 查询时间”这类页面右下角提示
phpMyAdmin 5.1 界面底部有时会显示类似 “SQL 查询时间：0.000 秒”，这个值是 PHP 脚本从发请求到收到 MySQL 响应的**整个 HTTP 请求周期耗时**，含网络延迟、PHP 解析、HTML 渲染等，跟 SQL 在 MySQL 内部真正执行多久完全无关。尤其在局域网环境，这个数字常低至 0.000，毫无参考价值。
生产环境真要盯耗时，得靠慢查询日志 + mysqldumpslow
单次手动测不准，也不反映真实负载。可靠做法是打开 MySQL 慢查询日志：
立即学习“PHP免费学习笔记（深入）”；
- 确认已启用：
SHOW VARIABLES LIKE 'slow_query_log'返回ON - 调低阈值：
SET GLOBAL long_query_time = 0.2（200ms，避免漏掉 OLTP 中的隐患语句） - 查日志文件路径：
SHOW VARIABLES LIKE 'slow_query_log_file'，然后用mysqldumpslow -s t -t 10 /path/to/slow.log提取总耗时 Top 10 - 注意：日志里
Query_time: 00:00:01.234567的小数点后六位是微秒，不是毫秒；若Lock_time接近Query_time，说明瓶颈在锁等待，不是 SQL 本身
真正难的不是抄命令，而是理解 Handler 状态和慢日志字段之间的映射关系——比如 Handler_read_rnd 高，往往对应 EXPLAIN 里 Extra 出现 Using filesort 或索引未覆盖 SELECT 字段。这些信号串起来，才构成一次有效的耗时归因。
