如何使用MySQL性能评估工具分析查询效率？

本文共计905个文字，预计阅读时间需要4分钟。

MySQL 的 `EXPLAIN` 是最直接的查询入口，但它仅做预估，不反映真实执行情况。若要查看效率，可使用 `profiling` 或 `SHOW PROFILES`。不过，这个功能在 MySQL 8.0.22 已被标记为废弃，生产环境更推荐使用 `performance_schema` 或 `slow_query_log` 配合 `long_query_time=0` 来捕获所有查询。

实操建议：

• 临时开启 profiling（仅用于调试）：SET profiling = 1;，执行完查 SHOW PROFILES; 和 SHOW PROFILE FOR QUERY N;
• 长期监控务必启用 performance_schema，尤其关注 events_statements_history_long 表，它记录最近的语句耗时、锁等待、磁盘 I/O 等真实指标
• 如果允许修改配置，把 slow_query_log = ON 和 long_query_time = 0 配上，再用 mysqldumpslow 或 pt-query-digest 分析日志

EXPLAIN 输出里哪些字段真正影响性能判断

EXPLAIN 的核心不是看“是否用了索引”，而是看“用了什么索引”和“扫了多少行”。type 字段值为 ALL 或 index 通常意味着全表/全索引扫描；rows 是优化器估算的扫描行数，和实际差距大时说明统计信息过期，需运行 ANALYZE TABLE。

关键注意点：

• key 显示实际使用的索引名，为空 ≠ 没走索引（可能走了覆盖索引但没显式列出）
• Extra 出现 Using filesort 或 Using temporary 是性能红灯，说明排序或分组没走索引
• filtered 值偏低（比如

为什么有些查询 EXPLAIN 看着快，但实际卡住几秒

因为 EXPLAIN 不体现锁等待、MVCC 版本链遍历、磁盘随机读延迟、CPU 调度竞争这些运行时开销。典型场景是：语句命中了索引，rows 也很小，但实际执行时被另一个长事务锁住了某几行，或者要回表读大量聚簇索引页导致 I/O 暴增。

排查这类问题必须跳出 EXPLAIN：

• 查 INFORMATION_SCHEMA.INNODB_TRX 和 INNODB_LOCK_WAITS，确认是否有阻塞链
• 用 SELECT * FROM performance_schema.events_statements_history_long WHERE SQL_TEXT LIKE '%your_query%' 查真实 LOCK_TIME 和 ROWS_EXAMINED
• 对比 ROWS_EXAMINED 和 ROWS_SENT，若前者远大于后者，大概率是回表或条件过滤低效

MySQL 8.0 推荐的轻量级性能观测组合

不用装第三方工具，靠内置模块就能搭出有效监控。重点不是全量采集，而是按需打开关键开关。

最小可行配置：

• 启用 performance_schema（默认已开），并确保 setup_consumers 中的 events_statements_* 和 events_waits_* 为 ENABLED
• 设置 performance_schema_max_digest_length = 2048，避免 SQL 被截断影响聚合分析
• 定期查 sys.statement_analysis 视图（sys schema 需手动安装），它自动汇总执行次数、平均延迟、全表扫描比例等实用指标

复杂点在于 performance_schema 默认内存限制较紧，高并发下容易丢事件；如果看到 events_statements_history_long 记录数突降，得调大 performance_schema_events_statements_history_long_size。这点容易被忽略，但直接影响你能不能抓到那条偶发的慢查询。