phpMyAdmin 4.9 无法直接查看 SQL 内部各阶段耗时，仅显示含网络与PHP开销的总耗时；需在SQL页手动执行 SET profiling = 1; → 目标SQL → SHOW PROFILES; → SHOW PROFILE FOR QUERY N; 查CPU/IO等细分耗时，且要求MySQL≥5.6、有PROCESS权限。
phpMyAdmin 4.9 里怎么看到 SQL 执行的详细耗时阶段
phpmyadmin 4.9 本身不展示 cpu、io、内存等细分耗时，它只在页面底部显示一个总耗时（如 query took 0.123 sec），这个数字是客户端从发请求到收响应的时间，含网络、php 层、mysql 网络往返，不能代表 sql 在 mysql 内部的真实开销。
要看到「MySQL 内部各阶段耗时」，必须用 MySQL 原生的 SHOW PROFILE，且需手动开启、手动查——phpMyAdmin 不提供一键开关或图形化 profile 面板。
实操建议：
- 先确认 MySQL 版本 ≥ 5.6 且已启用 profiling（
SELECT @@profiling;返回1） - 在 phpMyAdmin 的「SQL」页中，**必须连续执行三步**：
SET profiling = 1;→ 你的目标 SQL（如SELECT * FROM orders WHERE created_at > '2025-01-01';）→SHOW PROFILES; -
SHOW PROFILES;返回的Query_ID是倒序的，最新那条才是你刚跑的 SQL，别选错 - 若
SHOW PROFILES;为空，说明SET profiling = 1;没生效，常见原因是 MySQL 配置里禁用了 profiling（have_profiling = NO）或当前用户缺少PROCESS权限
SHOW PROFILE FOR QUERY N; 能看哪些真实有用的阶段
SHOW PROFILE FOR QUERY N; 默认只显示 Duration，但真正能定位瓶颈的是加参数的变体。不同参数反映不同资源压力，不是所有字段都稳定可用：
-
SHOW PROFILE CPU FOR QUERY N;：看User CPU和System CPU，高说明计算密集（如大字段排序、正则匹配） -
SHOW PROFILE BLOCK IO FOR QUERY N;：看Block_ops_in和Block_ops_out，非零值代表磁盘读写，高说明临时表或索引没进内存 -
SHOW PROFILE MEMORY FOR QUERY N;：仅 MySQL 5.7+ 支持，且只对Sorting、Grouping等少数操作上报，5.6 及更早版本始终为空 - 重点盯住
Creating tmp table和Coping to tmp table阶段耗时：若这两项明显长于其他阶段，基本可断定tmp_table_size或max_heap_table_size设置过小，导致本该在内存做的临时表被刷到磁盘
为什么 SHOW PROFILE 显示的耗时和慢日志/EXPLAIN 对不上
这是最常被误读的一点：SHOW PROFILE 记录的是单次执行的内部阶段时间，但它严重依赖会话状态和缓存情况。同一条 SQL 连续执行两次，Sending data 阶段可能从 80ms 掉到 5ms——因为第二次数据已在 InnoDB buffer pool 里。
立即学习“PHP免费学习笔记（深入）”；
所以不能拿一次 SHOW PROFILE 就下结论。实操建议：
- 每次测试前先清空相关缓存：
FLUSH STATUS;（重置 Handler 计数器）、RESET QUERY CACHE;（如果启用了查询缓存） - 至少执行 3 次目标 SQL，忽略第一次（冷启动），取后两次的
Duration平均值作为参考基准 - 若发现
Lock_time接近Query_time（查SHOW PROFILE FOR QUERY N;不直接给 Lock_time，得配合SHOW ENGINE INNODB STATUS\G看事务锁等待），说明瓶颈不在 SQL 本身，而在行锁/表锁争用 -
EXPLAIN显示type=ref但rows高达 50 万，而SHOW PROFILE里statistics阶段耗时极短、executing却很长——这说明索引虽然用了，但回表代价巨大，应考虑覆盖索引
替代方案：用慢日志 + EXPLAIN 配合验证
当 SHOW PROFILE 不可用（比如权限受限、MySQL
实操建议：
- 临时开启全局慢日志：
SET GLOBAL slow_query_log = ON;+SET GLOBAL long_query_time = 0.2;（别用默认 10 秒） - 确认日志路径：
SHOW VARIABLES LIKE 'slow_query_log_file';，然后用tail -f实时观察 - 对慢日志里的语句，回到 phpMyAdmin 手动执行
EXPLAIN FORMAT=JSON SELECT ...，重点关注execution_time字段（MySQL 5.7+）和used_columns是否全命中索引 - 避免只看
Query_time数值：日志里Query_time: 0.456789是微秒级精度，小数点后六位不能四舍五入成毫秒；真正关键的是Lock_time和Rows_sent/Rows_examined的比值，比值越低，过滤效率越差
真正难的不是查出耗时数字，而是判断「哪个阶段高是合理的、哪个高意味着配置或设计错了」。比如 Copying to tmp table 高，在 OLAP 场景可能是正常的；但在 OLTP 的用户列表页出现，就是索引缺失或 GROUP BY 写法不当的明确信号。
