SHOW PROFILE 是分析单条查询各阶段耗时最直接的手段，需先 SET profiling = 1 开启当前会话追踪，执行目标 SQL 后用 SHOW PROFILES 获取 Query_ID，再执行 SHOW PROFILE FOR QUERY N 查看 Status 和 Duration，重点关注 Copying to tmp table、Waiting for query cache lock、Sending data 等高耗时阶段。
用 SHOW PROFILE 查单条查询各阶段耗时
想看某次 SELECT 或 UPDATE 到底卡在哪一步（比如是不是在 Sorting result 或 Creating tmp table 上花太久），SHOW PROFILE 是最直接的手段。它不依赖日志文件，也不需要改 MySQL 配置，只要当前会话开启即可。
注意：它只对当前连接有效，数据存在内存里，断开或重启就清空；而且它不记录 SQL 文本本身，只记执行阶段和耗时分布。
- 先执行
SET profiling = 1;启用当前会话的追踪 - 再运行你要分析的语句，例如
SELECT * FROM orders WHERE status = 'pending' ORDER BY created_at DESC LIMIT 100; - 执行
SHOW PROFILES;查到刚那条语句的Query_ID（通常是 1） - 最后用
SHOW PROFILE FOR QUERY 1;看详细阶段，重点关注Status列和Duration列
常见高耗时阶段：Copying to tmp table（临时表太大）、Waiting for query cache lock（查询缓存争用）、Sending data（结果集大或网络慢）。
general_log 能看到完整 SQL，但看不到阶段细节
如果你需要确认“到底执行了哪条 SQL”，而不是“这条 SQL 内部哪步慢”，那就得靠 MySQL 的通用查询日志。它会原样记录所有发给服务器的语句，包括 phpMyAdmin 发起的每一条。
立即学习“PHP免费学习笔记（深入）”；
但它完全不提供执行阶段信息——你只能看到 SELECT ... 被执行了，却不知道它花了 200ms 还是 2s，也不知道这 2s 是花在解析、锁等待还是磁盘读上。
- 启用方式：在 MySQL 配置文件（如
/etc/my.cnf）的[mysqld]段加general_log = 1和general_log_file = /var/log/mysql/general.log - 必须确保 MySQL 进程对日志路径有写权限，否则静默失败
- 生产环境慎用：IO 开销大，日志增长快，且含敏感参数（如
WHERE id = 12345）
为什么 EXPLAIN 和 SHOW PROFILE 要配合着看
EXPLAIN 告诉你“理论上怎么走”，SHOW PROFILE 告诉你“实际上哪步拖后腿”。两者偏差越大，越说明实际执行和预估脱节。
- 如果
EXPLAIN显示type=ref且rows=100，但SHOW PROFILE里Creating sort index耗时 800ms，说明排序字段没索引，MySQL 强制用了文件排序 - 如果
EXPLAIN的key_len比预期小（比如字段定义为VARCHAR(191)却只用了 2 字节），而SHOW PROFILE中statistics阶段特别长，大概率是 WHERE 条件触发了隐式类型转换，导致索引失效 -
SHOW PROFILE里出现大量Waiting for table metadata lock，说明有长事务或 DDL 操作阻塞了查询，这时要立刻查SHOW PROCESSLIST;找出持有锁的连接
别指望 phpMyAdmin 界面直接显示阶段耗时
phpMyAdmin 不解析或展示 SHOW PROFILE 结果，也不集成慢日志分析。你看到的“执行时间：0.0234 秒”只是客户端从发请求到收响应的总耗时，包含网络延迟、PHP 处理、MySQL 执行三部分，无法拆解。
真正要定位瓶颈，必须手动进 SQL 标签页执行 SHOW PROFILE 系列命令，或者用命令行工具（如 mysql -e "SHOW PROFILE FOR QUERY 1;"）避免界面干扰。很多用户卡在这一步——以为点一下“执行”就能看到深度分析，其实得自己敲命令。
