EXPLAIN 展示优化器选择的执行计划 —— 它将如何访问每张表 —— 而不会真正运行查询。你通过它来确认索引被使用、且检查的行数很少。
const / eq_ref / ref（索引查找，好）→ range → index（全索引扫描）→ ALL（全表扫描，危险信号）。NULL = 没用索引）。Using index（覆盖，很好）、Using filesort / Using temporary（在内存或磁盘上排序/分组 —— 往往可优化）。EXPLAIN SELECT * FROM orders WHERE customer_id = 42 ORDER BY created_at;
-- +------+------+------+---------+--------+----------------+
-- | type | key | rows | Extra |
-- | ALL | NULL | 900k | Using where; Using filesort | <- 扫描全表，再排序
-- +------+------+------+---------+--------+----------------+
-- 添加一个同时覆盖过滤条件和排序顺序的索引：
CREATE INDEX idx_cust_created ON orders (customer_id, created_at);
EXPLAIN SELECT * FROM orders WHERE customer_id = 42 ORDER BY created_at;
-- | type | key | rows | Extra |
-- | ref | idx_cust_created | 30 | Using where | <- 定位 30 行，无 filesort
这个索引把对 90 万行的 ALL 扫描变成了只定位 30 行的 ref，而且由于 created_at 是第二列，返回的行已经是预排序的 —— filesort 消失了。
使用 EXPLAIN ANALYZE（MySQL 8）还能看到实际的耗时和行数，从而发现估算出错的情况。
EXPLAIN 让你用证据取代猜测。发现 type: ALL、巨大的 rows 或 Using filesort，就能准确地告诉你哪里缺了索引 —— 这是从"页面很慢"到有针对性修复的最快路径。
一个包含详细解答的 IT 面试题库——从初级到高级。
捐赠