type为ALL表示全表扫描，说明MySQL未使用索引；若rows接近总行数且Extra含Using where但无Using index，则索引失效。应检查WHERE字段是否建索引、遵循联合索引最左匹配、确保类型一致、避免索引列上函数操作。
EXPLAIN 显示 type 是 ALL，说明在全表扫描
这是最常见也最危险的信号：MySQL 没走索引，每查一次就扫一遍整张表。尤其当 rows 值接近表总行数，且 Extra 里出现 Using where（但没 Using index），基本可以断定索引失效。
实操建议：
- 检查
WHERE条件字段是否建了索引，注意联合索引的最左匹配原则——INDEX(a, b, c)能用上a = ?或a = ? AND b = ?，但对b = ?无效 - 确认字段类型和查询值类型一致，比如
user_id是BIGINT，但写成WHERE user_id = '123'（字符串）会触发隐式转换，索引失效 - 避免在索引列上做函数操作，
WHERE YEAR(create_time) = 2024不会走create_time索引；改用create_time >= '2024-01-01' AND create_time
EXPLAIN 的 key 为空，但明明建了索引
索引存在 ≠ 查询会用。MySQL 优化器可能认为走索引比全表扫描更慢（比如返回结果占表 20% 以上），于是主动放弃索引。
实操建议：
- 用
ANALYZE TABLE table_name更新统计信息，让优化器重估成本 - 加
FORCE INDEX强制走某索引（慎用）：SELECT * FROM orders FORCE INDEX (idx_user_status) WHERE user_id = 123 AND status = 'paid' - 检查索引选择性：如果
status只有 'paid'/'pending'/'failed' 三个值，这个字段单独建索引意义极小；更适合放在联合索引后位
EXPLAIN 中 Extra 出现 Using filesort 或 Using temporary
这不是错误，但意味着排序或分组没走索引，MySQL 得额外分配内存或磁盘临时表，性能损耗明显。尤其是 ORDER BY 和 GROUP BY 字段没被索引覆盖时高频出现。
实操建议：
-
ORDER BY a, b要高效，最好有联合索引INDEX(a, b)；若查询是WHERE a = ? ORDER BY b，这个索引也能完全覆盖 - 避免
SELECT *+ORDER BY，只查需要字段，减少排序开销；如果用了LIMIT，确保ORDER BY字段有索引，否则 MySQL 可能先排完整结果再截断 -
GROUP BY同理，优先用索引字段分组；如果必须按非索引字段分组，考虑提前物化中间结果（如写入临时表并加索引）
执行计划里 rows 预估严重不准，实际慢得多
MySQL 统计信息过期、数据分布倾斜（比如 95% 订单状态是 'pending'）、或者用了分区表但没正确收集各分区统计，都会导致 rows 偏差巨大，进而选错执行路径。
实操建议：
- 查当前统计信息更新时间：
SELECT UPDATE_TIME FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'your_db' AND TABLE_NAME = 'your_table' - 手动更新统计：
ANALYZE TABLE your_table（线上大表慎用，会锁表；MySQL 8.0+ 可用INFORMATION_SCHEMA.INNODB_TABLESTATS查看采样率） - 对极端倾斜字段（如状态字段），避免单独用于
WHERE，可结合高选择性字段构成联合条件，或用覆盖索引减少回表
真正卡住的往往不是单条 SQL 写得有多差，而是预估偏差让优化器“信错了人”。别光盯着 type 和 key，rows 和 Extra 才是藏问题的地方。
