MySQL小表不走索引不是bug，而是优化器基于IO与CPU成本权衡后主动选择全表扫描的合理行为；当EXPLAIN显示type=ALL但rows极小且Extra无回表提示时，说明全表扫描代价更低。
MySQL 在数据量少时不走索引，不是 bug，也不是配置错误，而是优化器基于成本（Cost-Based Optimization, CBO）主动选择的合理行为——它算出来全表扫描比走索引更快。
EXPLAIN 看到 type=ALL 就代表没走索引？不一定，要看 rows 和 Extra
执行 EXPLAIN SELECT * FROM users WHERE name = 'Alice' 时，如果看到 type=ALL，别急着删索引或加 FORCE INDEX。重点看两处：
-
rows值很小（比如 ≤ 10），说明优化器预估扫描行数极少 -
Extra字段为空或只有Using where，没有Using index condition或Using index，大概率是放弃了索引
这时不是“索引失效”，而是“索引被跳过”——因为回表开销（定位索引节点 + 再查聚簇索引取整行）比直接顺序读几页数据更重。
为什么小表走索引反而更慢？关键在 IO 和 CPU 权衡
InnoDB 的主键索引是 B+ 树，非主键索引叶子节点存的是主键值。哪怕 name 有索引，SELECT * 仍要回表。对 10 行的小表来说：
- 全表扫描：一次顺序读，可能就 1 个数据页（16KB），CPU 解析快
- 走索引：先查
name索引树（至少 1 次页读），再用主键去聚簇索引里逐条找（最多 10 次随机 IO） - 随机 IO 成本远高于顺序 IO，尤其在机械盘或高并发下更明显
优化器内部有一套代价模型（如 page_read_cost、cpu_cost），它会量化这些开销。当 rows 小到阈值（默认约 10–20 行），ALL 的 cost 就自动低于 range 或 ref。
什么时候该干预？别硬加 FORCE，先确认是否真需要
强行让小表走索引，通常没收益，还可能掩盖真实问题。只在以下情况考虑干预：
- 表虽小但会被高频查询（比如配置表），且后续会持续增长 → 提前建索引，避免后期突增延迟
- 你明确知道未来数据量会快速上升（如日志归档表刚初始化）→ 可用
ANALYZE TABLE users更新统计信息，让优化器“预见”趋势 - 调试阶段想验证索引结构是否有效 → 临时用
FORCE INDEX(idx_name)，但上线前务必撤掉 - 用
SELECT COUNT(*)这类聚合时，即使小表也建议加覆盖索引（如KEY idx_name (name)），避免全表扫描计数
最常被忽略的一点：优化器依赖的统计信息可能滞后。刚插入 10 万行却没 ANALYZE，它仍按 10 行估算，导致大表也误判为“小表”。ANALYZE TABLE 不耗资源，上线后定期跑比瞎调 FORCE 实在得多。
