要查看select语句实际耗时与扫描行数，应使用performance_schema或慢日志（long_query_time=0），而非已废弃的profiling；explain中需重点关注type、rows、key和extra字段。
怎么看一个 SELECT 语句实际花了多少时间、扫描了多少行
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。这点容易被忽略，但直接影响你能不能抓到那条偶发的慢查询。
