优化器选择全表扫描而非索引是因为其基于I/O成本模型估算顺序读聚簇索引比随机读二级索引加回表更优；当回表行数多、未覆盖查询列、ORDER BY不匹配、索引区分度低时会放弃二级索引。
优化器不是“不走索引”，而是算出来全表扫描更便宜。 它基于 I/O 成本模型做决策，顺序读聚簇索引（即全表扫描）在多数场景下比随机读二级索引 + 回表更快。
为什么全表扫描有时比走索引还快？
InnoDB 的“全表扫描”本质是顺序遍历主键 B+ 树的叶子节点——这是最稳定的顺序 I/O；而二级索引查询需先查索引页（可能跨页），再根据主键逐条回表（大量随机 I/O）。当以下任一情况成立时，优化器就会放弃二级索引：
- 预估要回表的行数太多（比如
WHERE status = 1匹配 80% 行，rows接近TABLE_ROWS） -
SELECT *或查询列未被索引覆盖，必须回表取完整行 -
ORDER BY字段不在索引中，或顺序不匹配（如索引是idx_source_id，却按id排序） - 二级索引本身区分度极低（
CARDINALITY / TABLE_ROWS ），优化器认为它筛不掉几行
如何确认是不是统计信息失真导致的？
CARDINALITY 是优化器估算筛选能力的核心依据，但它只是采样估算值，极易失真。常见失真信号包括：
-
SHOW INDEX FROM mapping_filter_record WHERE Key_name = 'idx_source_id'中CARDINALITY明显偏低（如总行 400 万，CARDINALITY = 3） - 肉眼可见字段有几十个不同值，但
information_schema.STATISTICS里显示为 1 或 2 - 执行
ANALYZE TABLE mapping_filter_record后，EXPLAIN计划立刻变化
长期可用方案：SET GLOBAL innodb_stats_persistent = ON + innodb_stats_auto_recalc = ON，避免手动刷新遗漏。
哪些 WHERE 写法会让索引“形同虚设”？
即使索引结构合理，SQL 写法也可能让优化器无法生成可检索的范围条件（non-sargable）：
- 对索引列用函数：
WHERE DATE(create_time) = '2026-06-01'→ 改成create_time >= '2026-06-01' AND create_time - 隐式类型转换：
WHERE phone = 13800001111（phone是VARCHAR）→ 改成WHERE phone = '13800001111' - 联合索引跳过最左前缀：
INDEX(a, b, c)，却只写WHERE b = 1 AND c = 2 - 范围查询后接等值：
WHERE a = 1 AND b > 10 AND c = 'x'→c列无法使用索引
怎么验证优化器到底在想什么？
EXPLAIN FORMAT=JSON 和 optimizer_trace 是唯二能看清“为什么没选索引”的工具：
-
EXPLAIN FORMAT=JSON会输出"cost_info": {"query_cost": "3865.20"}，还能看到每个候选索引的预估成本 -
SET optimizer_trace="enabled=on"; SELECT ...; SELECT * FROM information_schema.OPTIMIZER_TRACE;可查到优化器逐个评估索引、计算 I/O 和 CPU 成本的全过程 - 注意：
EXPLAIN默认只告诉你“选了什么”，不告诉你“为什么没选别的”
真正容易被忽略的是：执行计划不是 SQL 的固有属性，而是 SQL + 参数 + 数据分布 + 统计信息 + MySQL 版本 的联合产物。同一句 SQL，在测试库走索引，上线后全表扫描，大概率是数据倾斜或统计未更新所致。
