ALL 类型表示全表扫描，是典型性能问题：未走索引，逐行读取；若 rows 接近总行数且 Extra 含 Using filesort 或 Using temporary，则查询已失控。
Explain 显示 type 是 ALL，说明全表扫描了
这是最典型的性能信号：没走索引，MySQL 正在一行行读完整张表。尤其当 rows 值接近表总行数，且 Extra 里出现 Using filesort 或 Using temporary，基本可以断定查询已失控。
常见诱因包括：WHERE 条件字段没索引、用了函数（如 WHERE YEAR(create_time) = 2023）、隐式类型转换（varchar 字段和数字比较）、或者 OR 连接多个非索引字段。
- 先用
SHOW CREATE TABLE table_name看字段类型和现有索引 - 检查
WHERE中每个字段是否都落在某个索引的最左前缀上 - 避免在索引字段上做计算或函数操作；改写为范围查询，例如把
YEAR(create_time) = 2023换成create_time BETWEEN '2023-01-01' AND '2023-12-31'
复合索引该按什么顺序建：CREATE INDEX idx_a_b_c ON t(a,b,c)
顺序不是随意排的，它直接决定哪些查询能命中。核心原则是：**最常用于等值查询（=）的字段放最左，范围查询（>, BETWEEN, LIKE 'abc%'）字段放中间，排序或分组字段（ORDER BY, GROUP BY）放最后**。
比如查询常写成 WHERE status = 1 AND create_time > '2024-01-01' ORDER BY id DESC，那索引就该是 idx_status_create_time_id，而不是反过来。
-
status = 1 AND id = 100能用上(status, id)，但id = 100 AND status = 1同样能——MySQL 优化器会自动调整顺序匹配 -
WHERE a > 10 AND b = 2只能用到a，b索引失效；必须把b放a左边才能生效 - 不要盲目给所有
WHERE字段都加单列索引，重复索引（如已有(a,b)，再建(a)）反而拖慢写入
EXPLAIN FORMAT=JSON 比传统输出多看出什么
普通 EXPLAIN 看不到代价估算细节，而 FORMAT=JSON 会暴露 MySQL 内部的“决策依据”，比如它为什么放弃某个索引、预估扫描多少行、是否用到 ICP（索引条件下推）。
重点关注 query_cost、used_columns、attached_condition 和 using_index_condition: true 这几项。如果 used_columns 明显少于你 WHERE 里的字段，说明有字段根本没参与索引查找。
- 执行
EXPLAIN FORMAT=JSON SELECT ...后，直接搜"used_columns"和"key_length" - 若
"using_index_condition": false，但你的条件明明能走索引，大概率是字段类型不一致（比如utf8mb4对比utf8）或统计信息过期，可运行ANALYZE TABLE table_name - 注意
"filtered"值：低于 10 表示即使走了索引，也要过滤掉绝大多数行，可能需要更精准的索引覆盖
加了索引还是慢？查查是不是 SELECT * 拖垮了
索引本身只加速定位，不加速取数据。如果 SELECT * 返回大量字段，尤其包含 TEXT、BLOB 或长 VARCHAR，MySQL 就得回表（Using where; Using index 不成立），磁盘 IO 成倍增加。
这时候「覆盖索引」就关键了：让索引里直接包含 SELECT 和 WHERE 所需的所有字段，避免回表。
- 把
SELECT *改成明确列出需要的字段，再看EXPLAIN的Extra是否变成Using index - 覆盖索引要包含所有
WHERE、SELECT、ORDER BY、GROUP BY字段；顺序仍遵循最左前缀原则 - 别为了覆盖索引无限制加字段——索引变宽会降低缓存效率，单行索引建议控制在 2000 字节内
索引不是银弹，尤其是涉及 JOIN 多表、GROUP BY 大结果集、或数据分布极度倾斜（比如 99% 的 status = 1）时，EXPLAIN 显示“走了索引”也可能只是幻觉。真正卡点往往藏在执行计划没说清的磁盘随机读、Buffer Pool 命中率、甚至从库复制延迟里。
