SHOW STATUS 返回的是 MySQL 服务器自启动以来的累计状态变量值，如 Queries、Sort_scan、Created_tmp_tables，不反映单条 SQL 的执行开销。
SHOW STATUS 返回的是什么数据
SHOW STATUS 查看的不是单条 SQL 的执行开销，而是 MySQL 服务器自启动以来的累计状态变量值，比如 Queries、Sort_scan、Created_tmp_tables。它不记录某次查询耗时、扫描行数或执行计划，也不支持按会话或语句粒度过滤——这点常被误用。
如果你刚执行了一条慢查询，立刻运行 SHOW STATUS，几乎看不到它带来的“突变”，因为多数指标增长极小（例如 Handler_read_next 可能+100，但你无法关联到具体哪条语句）。
哪些 STATUS 变量和 SQL 开销真正相关
真正反映底层执行压力的变量集中在 Handler_* 和 Sort_* 类别，它们对应存储引擎层的操作次数：
-
Handler_read_first：索引首次定位次数，高说明大量全索引扫描 -
Handler_read_next：索引顺序读取次数，配合Handler_read_key可判断是否有效利用索引范围扫描 -
Handler_read_rnd：基于随机主键回表次数，值高往往意味着Using filesort或Using temporary -
Sort_merge_passes：排序归并轮数，大于 0 表示内存 sort_buffer_size 不足，已触发磁盘排序 -
Created_tmp_disk_tables：隐式临时表落盘次数，比Created_tmp_tables更值得关注
注意：Slow_queries 只统计超过 long_query_time 的语句，不反映开销成因；Threads_created 是连接池问题，和单条 SQL 无关。
如何用 SHOW STATUS 定位真实开销变化
必须做差值对比，且限定在**同一会话**中执行前后快照：
- 先执行
FLUSH STATUS（仅重置当前会话的会话级状态，不影响全局） - 再执行目标 SQL（建议加
/*+ MAX_EXECUTION_TIME(1000) */防卡死） - 立即执行
SHOW STATUS LIKE 'Handler_%'和SHOW STATUS LIKE 'Sort%' - 重点关注 Handler 增量是否远超预期行数（例如查 100 行却触发 5000 次
Handler_read_next，大概率索引失效）
示例对比逻辑：
mysql> FLUSH STATUS; mysql> SELECT * FROM orders WHERE user_id = 123 AND status = 'paid'; mysql> SHOW STATUS LIKE 'Handler_read%';
输出中若 Handler_read_next 值为 12800 而结果集仅 12 行，基本可断定 user_id 上无有效索引或存在隐式类型转换。
比 SHOW STATUS 更直接的替代方案
真要看单条 SQL 开销，优先用这些：
-
EXPLAIN FORMAT=tree（MySQL 8.0+）：直接展示执行计划树和预估成本 -
SET profiling = 1;后执行 SQL，再查SHOW PROFILES和SHOW PROFILE FOR QUERY N（已废弃但仍可用，注意 8.0 默认关闭 performance_schema 时 profiling 不生效） - 开启
performance_schema并查询events_statements_history_long，配合events_stages_history_long看各阶段耗时（需提前设置consumers） - 慢日志 +
pt-query-digest分析聚合开销分布
SHOW STATUS 的价值在于宏观趋势观测（如 Created_tmp_disk_tables 持续上升），而非诊断单次查询。拿它当“实时 profiler”用，容易得出错误归因。
