MySQL索引未被使用是因优化器基于成本选择全表扫描，非索引失效；EXPLAIN中type=ALL或key=NULL即为确诊信号，配合rows接近总行数、filtered极低、key_len异常偏小、Cardinality失真、回表开销大、WHERE条件不可检索等可定位根因。
MySQL 有索引却走全表扫描，不是索引“失效”了，而是优化器算了一笔账：走索引更贵，所以主动选了 type=ALL。
EXPLAIN 显示 type=ALL 或 key=NULL 就是确诊信号
别被“索引存在”骗了。type=ALL 表示优化器决定顺序扫描聚簇索引叶子节点；key=NULL 表示没用上你建的任何二级索引。这两个字段任一出现，就说明索引被评估后否决了，不是没建好，是成本太高。
-
rows接近表总行数（比如 100 万行的表，rows=923410），基本等于全扫 -
filtered极低（如1.00），说明 WHERE 条件几乎没过滤能力 - 联合索引下
key_len比预期小很多（比如idx_a_b_c预期用满三层，但key_len只显示用了前两层），大概率中间某列因范围查询或类型不匹配被截断
统计信息失真会让优化器“看错”数据分布
Cardinality 是优化器估算成本的关键输入，但它不是精确值，而是采样估算结果。如果表经历过大批量导入、长期未更新，这个值可能严重失真——比如总行数 500 万，Cardinality 却只报 2 万，优化器一看：“这索引区分度太差”，直接弃用。
- 查当前基数：
SHOW INDEX FROM t WHERE Key_name = 'idx_status'，重点看Cardinality是否明显偏低 - 强制刷新：
ANALYZE TABLE t（注意：该操作会锁表，生产环境避开高峰） - 长期方案：设
innodb_stats_persistent=ON+innodb_stats_auto_recalc=ON，让 MySQL 自动维护统计信息
回表开销大时，PRIMARY 扫描反而更便宜
二级索引叶子节点只存索引列 + 主键，SELECT * 必须回表取整行。而回表是随机 I/O，每回一次都要跳去聚簇索引另一位置读一页。优化器预估要回表几十次，成本就很容易超过顺序扫描几页聚簇索引。
- 你的
idx_source_id是(source_id, source_type, state)，但查询要SELECT *→ 必然回表 -
ORDER BY id ASC LIMIT 1无法利用该索引排序（id不在索引中，且顺序不连续）→ 还得额外比对或排序 - 优化器用
EXPLAIN FORMAT=JSON算过：query_cost比走PRIMARY高一截，所以选主键扫描，碰到第一条匹配就停
WHERE 条件写法让索引“不可检索”（non-sargable）
优化器无法把条件转换成连续的 B+Tree 搜索区间，索引就失去快速定位能力。这不是语法错误，而是语义上破坏了有序性。
- 对索引列做函数：如
WHERE YEAR(create_time) = 2023、WHERE UPPER(name) = 'ABC' - 隐式类型转换：如
varchar字段传数字WHERE code IN (123)，触发字符串转数字，等价于对字段加函数 - 前置通配符模糊匹配：
WHERE name LIKE '%abc'，无法利用 B+Tree 的有序性 -
IN子查询返回大量结果（尤其含NULL），或外层IN列命中率过高（>30%），优化器常直接降级为全表扫描
真正危险的是 rows 和 key_len 共同暴露的“假索引”：看起来走了索引（type=ref），但 rows 高得离谱、key_len 又异常偏小，说明实际只用了索引最左侧一两列，过滤效果极差——这种索引不如删掉，它只会拖慢写入、干扰优化器判断。
