mysql全表扫描是优化器权衡成本后的主动选择，type=all即表示逐行扫描整张表；key=null不代表无索引，仅说明本次查询未使用索引，根本原因在于优化器估算走索引成本高于全表扫描。
MySQL全表扫描不是“出错了”，而是优化器在权衡之后的主动选择——只要看到 EXPLAIN 中 type = ALL，就说明这条 SQL 当前必定逐行扫描整张表，没有走任何索引。
为什么明明有索引，却还是全表扫描
索引存在 ≠ 索引被用。优化器会估算走索引的成本（比如回表、随机 IO）和全表扫描的成本（顺序 IO + CPU 过滤），选更便宜的那个。常见触发点包括：
-
WHERE条件对索引列用了函数，比如YEAR(create_time) = 2023或UPPER(name) = 'ADMIN'，索引结构被破坏，无法定位 - 字段类型不匹配：索引列是
VARCHAR，但查询传了数字（WHERE code = 123），MySQL 自动做隐式转换，等价于WHERE CAST(code AS SIGNED) = 123，索引失效 - 联合索引没遵守最左前缀：建了
INDEX(a, b, c)，但只查WHERE b = ?或WHERE c = ?，前面字段缺失，索引直接跳过 - 查询返回数据太多：比如
status只有 3 个值，查WHERE status = 'paid'预估返回 40% 行数，优化器认为回表代价远高于顺序扫表，主动弃用索引
为什么小表也显示 type = ALL
这不是 bug，是合理策略。表只有几百行时，加载一个数据页就能覆盖全表，顺序读比维护 B+ 树导航、跳转指针、反复回表更轻量。此时 type = ALL 反而是最优执行路径——它不等于“慢”，只是没走索引而已。
但要注意：小表在高并发下依然危险。每秒 500 次全表扫描，哪怕每次 2ms，也会吃掉大量 CPU 和 Buffer Pool，挤占真正需要索引的查询资源。
IN / NOT IN 为什么经常触发全表扫描
IN 在优化器内部常被展开为多个 OR，只要其中一项不满足索引使用条件（比如类型不对、字段无索引），整条语句就降级为全表扫描。
NOT IN 更敏感：子查询结果里只要含一个 NULL，整个表达式结果恒为 UNKNOWN，MySQL 放弃索引，强制过滤每一行。
替代方案优先用 EXISTS：它能利用关联字段上的索引做半连接查找，找到第一个匹配就终止，天然规避大量扫描。
key 为空不代表没索引
EXPLAIN 中 key = NULL 不代表你没建索引，只代表这次查询优化器决定不用它。背后原因可能是：
- 统计信息过期：
ANALYZE TABLE没跑过，优化器基于错误的行数估算做出误判 - 索引选择性太低：比如给性别字段建单列索引，两值分布极度倾斜，优化器预估几乎不减少扫描量
- 查询中混用了
OR且部分分支无索引，导致整条语句退化
真正要盯住的是 rows 字段——它反映优化器预估扫描行数；如果这个数接近表总行数，无论 key 是否为空，实际都在全表扫描。
