explain和profile是mysql最常用查询性能分析手段：explain查看执行计划，关注type、key、rows、extra字段；profile定位各阶段真实耗时，需先set profiling=1，再用show profiles和show profile for query n分析。
EXPLAIN 和 PROFILE 是 MySQL 中最常用、最直接的查询性能分析手段。它们不依赖外部工具，能快速定位慢查询的瓶颈所在：是全表扫描？索引没用上？还是临时表/文件排序拖了后腿？掌握这两个命令的实际解读方法，比盲目加索引或调参数更有效。
用 EXPLAIN 看执行计划的关键字段
在 SQL 前加 EXPLAIN（如 EXPLAIN select * FROM orders WHERE user_id = 123;），关注以下几列：
- type：连接类型，从好到差通常是
const≈eq_ref>ref>range>index>ALL。出现ALL说明走了全表扫描，优先检查是否缺索引或索引失效（比如对索引字段用了函数、隐式类型转换）。 - key：实际使用的索引名。为
NULL表示没走索引；若值存在但rows很大，可能是索引选择性差或条件过滤率低。 - rows：MySQL 预估需要扫描的行数。这个值越接近实际结果集大小越好；远大于结果行数，常意味着索引未覆盖查询字段，导致回表，或索引区分度低。
- Extra：重要提示区。看到
using filesort表示需要额外排序（没走索引排序）；Using temporary表示创建了临时表（常见于 GROUP BY 或 DISTINCT 无合适索引时）；Using index是好消息，表示走了覆盖索引，无需回表。
用 PROFILE 定位耗时环节
PROFILE 能展示语句执行各阶段的真实耗时（需先开启：SET profiling = 1;），适合已知某条语句慢，但 EXPLAIN 看不出明显问题的情况。
- 执行完慢查询后，运行
SHOW PROFILES;查看最近执行语句的 ID 和总耗时。 - 再用
SHOW PROFILE FOR QUERY N;（N 是 ID）查看该语句在各个阶段（如starting、executing、Sorting result、Sending data）的具体时间。 - 重点关注耗时占比高的阶段：如果
Creating tmp table或Copying to tmp table时间长，说明临时表开销大；如果Sending data占比异常高，可能是返回结果集太大或网络/客户端处理慢。
组合使用的小技巧
单独看 EXPLAIN 只能看到“计划”，PROFILE 只反映“执行”，两者结合才能闭环分析：
- 先用
EXPLAIN检查是否走了预期索引、有无filesort或temporary；如果没问题但依然慢，立刻切到PROFILE看真实瓶颈在哪一环。 - 修改 SQL 或加索引后，对比前后两次
EXPLAIN的rows和Extra，再用PROFILE验证耗时是否下降——避免“看起来优化了，实际没改善”。 - 注意
PROFILE在 MySQL 8.0 中已被标记为废弃（推荐用 Performance Schema），但 5.7 及之前版本仍非常实用，日常诊断足够可靠。
别忽略基础但关键的上下文
分析结果必须结合实际数据和业务场景判断：
- 小表（比如几百行）走
ALL不一定有问题；大表（千万级）哪怕rows预估只有 1 万，也可能因磁盘 I/O 成为瓶颈。 -
EXPLAIN的rows是估算值，受统计信息影响。如果表数据变动频繁，可手动更新统计信息：ANALYZE TABLE table_name;。 - 避免只看单条 SQL。一个接口慢，可能由多条查询叠加导致，用
PROFILE分别检查每条，再看整体分布。