type=ALL表示MySQL已确定全表扫描，必然导致性能下降；需先确认WHERE字段是否缺失索引、类型不匹配或函数滥用，再针对性优化。
type=ALL说明MySQL正在全表扫描，不是“可能慢”，是已经慢了
只要EXPLAIN里type显示ALL，就代表MySQL打算逐行读取整张表——哪怕只有几千行，在并发稍高时也会明显卡顿。这不是预估偏差，而是执行计划明确选择的最便宜路径（通常因为没索引、索引失效或统计信息严重过期）。别急着加索引，先确认它是不是真该被优化。
检查WHERE条件字段是否缺失索引或类型不匹配
最常见的原因是查询字段根本没建索引，或者建了但用不上。比如SELECT * FROM orders WHERE user_id = 123，EXPLAIN显示type=ALL，先查SHOW INDEX FROM orders看user_id是否在Key_name里：
- 没索引？直接加：
ALTER TABLE orders ADD INDEX idx_user_id (user_id) - 有索引但
key列为NULL？检查字段类型是否一致——比如user_id是INT，但查询写成WHERE user_id = '123'，隐式转换会让索引失效 - WHERE用了函数？如
WHERE DATE(create_time) = '2023-01-01'，索引列被包装后无法走索引，应改用范围写法：WHERE create_time >= '2023-01-01' AND create_time
复合查询优先用联合索引，注意最左前缀和顺序
单列索引在多条件查询中常被忽略。例如WHERE user_id = 123 AND status = 'paid'，即使user_id和status各自都有单列索引，优化器也可能放弃任一索引而选全表扫描。这时应建联合索引：
Mysql Skill 1.0.0 (3)
下载
MySQL 数据库管理技能，能够通过自然语言查询和管理数据库，支持 SELECT/INSERT/UPDATE/DELETE、表管理、备份恢复等操作。当用户提及 MySQL、数据库查询、建表或数据备份时使用此技能。
- 等值条件放前面：
INDEX idx_user_status (user_id, status)，不能反过来 - 如果还有
ORDER BY created_at，且需要避免Using filesort，可扩展为INDEX idx_user_status_created (user_id, status, created_at) - 注意
key_len是否符合预期：比如user_id是INT NOT NULL（4字节），status是VARCHAR(20)（最大20+1字节），那key_len应为25；若远小于此值，说明后缀列没参与查找
rows估算严重偏大时，别只盯着索引，先跑ANALYZE TABLE
rows是优化器基于统计信息的估算值，不是真实扫描数。如果rows显示百万级，但实际只返回几十行，大概率是统计信息过期——尤其在大批量INSERT/DELETE后。这时加索引可能无效，甚至让优化器绕开更优路径：
- 执行
ANALYZE TABLE orders强制更新统计信息 - 再跑一次
EXPLAIN，看rows是否回落、type是否变成ref或range - 若仍为
ALL，再考虑FORCE INDEX临时验证索引是否真能起效，但生产环境慎用
真正容易被忽略的是：type=ALL有时反而是合理选择——比如表只有几百行，或WHERE条件涉及JSON字段、全文模糊匹配等无法走索引的场景。盲目加索引不仅无效，还会拖慢写入。先看rows和数据量级，再决定要不要动索引。
