EXPLAIN显示type=ALL代表MySQL放弃索引、逐行扫描整张表以匹配WHERE条件；它由优化器基于成本模型决策，常见原因包括索引缺失、函数操作、隐式转换、最左前缀不匹配及低选择性等。
为什么 EXPLAIN 显示 type=ALL 就代表全表扫描？
type=ALL 是 EXPLAIN 输出中明确标识“没有使用任何索引、必须遍历整张表”的信号。它不等于“慢”，但意味着 MySQL 放弃了索引查找路径，转而逐行检查每一行是否满足 WHERE 条件。常见诱因不是数据量大，而是查询写法或索引缺失直接切断了优化器的索引选择机会。
注意：type=ALL 和 rows 值要一起看——如果 rows 接近表总行数（比如 rows=98765 而 SELECT COUNT(*) FROM t 返回 100000），基本可确认是实质全扫；但如果 rows 很小（如 100），可能是优化器预估偏差，实际未必真扫全表。
哪些 WHERE 条件会强制触发 type=ALL？
即使有索引，以下写法也会让优化器无法使用它：
- 对索引列使用函数或表达式：
WHERE YEAR(created_at) = 2024（created_at有索引也无效） - 隐式类型转换：
WHERE user_id = '123'（user_id是INT，字符串字面量触发全表转换比较） - 前导通配符的
LIKE：WHERE name LIKE '%abc'（B-tree索引无法从右端开始匹配） - 使用
OR连接非同索引字段：WHERE a = 1 OR b = 2（若a和b没有联合索引，通常退化为全表）
验证方式：把对应条件单独拎出来执行 EXPLAIN，观察 key 列是否为空、possible_keys 是否包含预期索引。
如何用 EXPLAIN FORMAT=TREE 快速定位扫描根源？
MySQL 8.0+ 的树形格式比传统表格更直观地展示“为什么没走索引”。它会显式写出访问方法（table_scan 或 index_range_scan）和过滤条件（filter）。
执行示例：
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
EXPLAIN FORMAT=TREE SELECT * FROM orders WHERE status = 'shipped' AND amount > 100;
如果输出中出现：
-> Table scan on orders (cost=...)
就说明连 status 这个常见筛选字段都没走索引——大概率是 status 列没建索引，或索引被其他条件“拖累”失效。此时再查 SHOW CREATE TABLE orders，确认 status 是否在某个联合索引的最左前缀位置。
复合索引顺序不对也会导致 type=ALL 吗？
会。例如表上有联合索引 INDEX idx_a_b_c (a,b,c)，但查询是 WHERE b = 2 AND c = 3，EXPLAIN 中 key 仍为空。因为 B-tree 索引要求最左前缀匹配，跳过 a 直接查 b，索引结构上无法定位起始点。
修复思路不是盲目加索引，而是结合高频查询模式调整：
- 若
WHERE b = ? AND c = ?频率远高于WHERE a = ?，考虑新建INDEX idx_b_c (b,c) - 若两者都高频，且常与
a组合，优先建INDEX idx_b_c_a (b,c,a)（把高频过滤字段放前面） - 避免过度索引：一个表上
idx_a_b和idx_a_b_c同时存在，后者通常已覆盖前者作用
真正容易被忽略的是：ORDER BY 和 GROUP BY 字段如果不在索引覆盖范围内，也可能让优化器放弃已有索引，转而选择全表扫描后排序——这时 EXPLAIN 的 Extra 列会出现 Using filesort 或 Using temporary，它们常与 type=ALL 并存，需一并处理。
