第一次读 EXPLAIN：先看表访问方式与扫描行数

归档日期：2026-10-27；补录发布：2026-10-28。

慢查询日志提示哪些 SQL 值得关注，EXPLAIN 帮助理解优化器准备怎样执行。先能解释访问什么表、选择什么索引、预计扫描多少行，比背下每一列更实用。

从只读示例开始

EXPLAIN
SELECT cid, title
FROM typecho_contents
WHERE type = 'post' AND status = 'publish'
ORDER BY created DESC
LIMIT 10;

这是 Typecho 风格的示例，实际表前缀和字段先确认。普通 EXPLAIN 通常展示计划，不等于业务查询实测耗时，也可能需要元数据锁等资源。

先看这些列

table 表示当前步骤访问的表，type 是访问方式，possible_keys 是候选索引，key 是实际选择的索引，rows 是预计检查行数，Extra 提供排序和过滤等信息。

rows 是估计值，数据分布和统计信息都会影响它，不能写成实测扫描行数。

不要只凭一个词下结论

ALL 通常表示全表扫描。大表频繁全扫值得关注，小表全扫却可能合理。索引不是越多越好，它增加存储和写入维护成本。

Using filesort 表示不能直接按所选索引顺序完成排序，不等于一定发生磁盘文件排序。Using temporary 表示使用内部临时表，也不能单靠它判断严重程度。

ANALYZE 会实际执行

MySQL 8 支持的 EXPLAIN ANALYZE 会执行受支持的语句并提供运行信息。它不是普通 EXPLAIN 的无影响替代品，即使是 SELECT 也可能扫描大量数据或等待锁。

初次练习选择测试环境、小数据量、明确的只读查询，不在业务繁忙时分析未知大查询。

留下优化对照

保存原 SQL、数据规模、计划和响应时间。考虑复合索引时还要理解选择性、排序、条件与最左前缀，先测试再准备上线和回退。

这一阶段的目标是看懂计划并提出合理问题，而不是遇到慢查询就立即建索引。本文示例不代表本站发生过该慢查询。

怎样把优化结论说清楚

先记录表行数、索引定义与数据分布，再解释计划。即使 key 变为目标索引，也要比较真实耗时和业务负载。LIMIT 10 不保证只扫描十行，可能先扫描和排序大量记录。不要在本文直接创建所谓万能复合索引，测试库验证后才评估写入成本、上线方式和回退。

内容复核与修订：2026-10-29。实验示例与本站运行记录分别说明；原始归档日期保留。