type为ALL或index表示全表或全索引扫描，是索引未命中的直接信号；ALL逐行扫表，index遍历整棵索引树，均属低效访问，常见于函数操作、隐式转换、联合索引不满足最左前缀等场景。
EXPLAIN 输出里 type 为 ALL 或 index 意味着全表扫描
这通常是最直接的索引未命中信号。MySQL 在 type 列显示访问类型，ALL 表示逐行扫描整张表，index 是遍历整个索引树（仍属低效）。不是所有查询都必须达到 ref 或 range，但若数据量超过几千行还出现 ALL，基本可断定没走有效索引。
常见诱因包括：
- WHERE 条件中对索引列用了函数，比如
WHERE YEAR(create_time) = 2024—— 索引失效，改用create_time BETWEEN '2024-01-01' AND '2024-12-31' - 隐式类型转换，例如字段是
VARCHAR，但查询写成WHERE user_id = 123（数字），MySQL 自动转类型导致索引不走 - 联合索引最左前缀未被满足，如索引是
(a, b, c)，却只查WHERE b = 2 AND c = 3，a缺失则整个索引无法利用
key 为空或与预期不符，说明优化器没选你建的索引
EXPLAIN 的 key 列显示实际使用的索引名。如果它是 NULL，代表没用任何索引；如果它显示了某个索引，但不是你期望的那个（比如你建了 idx_status_created，它却用了 PRIMARY），就得怀疑优化器的代价估算是否合理。
这时要检查：
- 该索引是否被标记为
DISABLED（可通过SHOW INDEX FROM table_name确认Comment列） - 索引列上是否有大量重复值（如
status只有 0/1，选择性太低，优化器可能认为全扫更快） - 是否因
SQL_NO_CACHE或统计信息过期，导致执行计划不准：运行ANALYZE TABLE table_name更新统计信息再试
Extra 出现 Using filesort 或 Using temporary 常伴随索引设计缺陷
这两个提示本身不等于“没走索引”，但往往暴露索引覆盖不足的问题。例如 ORDER BY created_at 时，如果 created_at 不在 WHERE 条件用到的索引中，或不在联合索引最右位置，MySQL 就得额外排序 —— 即使 WHERE 走了索引，Using filesort 仍会出现。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
典型修复方式：
- 把排序字段加入 WHERE 所用索引的尾部，如原索引是
(user_id)，而常查WHERE user_id = ? ORDER BY created_at，就建(user_id, created_at) -
SELECT *容易触发Using temporary，尤其配合GROUP BY或DISTINCT；尽量明确字段，并确保这些字段能被同一索引覆盖（即“覆盖索引”） - 注意
LIKE查询：以通配符开头（LIKE '%abc'）必然无法使用 B+Tree 索引，此时考虑全文索引或倒排结构
为什么 EXPLAIN FORMAT=JSON 比传统格式更值得习惯性使用
普通 EXPLAIN 只给主干信息，而 EXPLAIN FORMAT=JSON 会暴露优化器的真实决策路径，比如 used_key_parts 显示实际用到了联合索引哪几列，rows_examined_per_scan 和 rows_produced_per_join 能帮你判断估算是否离谱。
一个实用技巧：
- 对比
EXPLAIN和EXPLAIN FORMAT=JSON中的filtered值（百分比），若远低于 10%，说明该条件过滤性极差，可能是索引列顺序或数据分布问题 - 留意
attached_condition字段，它会写出那些“本该下推到存储引擎却没能下推”的条件，往往是隐式转换或复杂表达式的锅
真正卡住排查进度的，常常不是“有没有索引”，而是“为什么优化器觉得这个索引不划算”。多看 JSON 格式里的成本估算和条件拆解，比反复删重建索引更省时间。
