MySQL优化器基于成本选择执行计划，若索引总成本高于全表扫描则弃用；EXPLAIN中type=ALL或key=NULL表明索引被否决，rows接近总行数、key_len异常偏小、Cardinality失真、回表开销大等均会导致索引失效。
MySQL优化器不是“看到索引就用”，而是算了一笔账：走索引要读多少页、回几次表、排不排序、临时表要不要建——总成本比全表扫描（准确说是聚簇索引顺序扫描）还高，它就会主动放弃索引。
EXPLAIN 显示 type=ALL 或 key=NULL 就是确诊了
别被“索引存在”骗了。type=ALL 表示优化器决定遍历整个聚簇索引叶子节点；key=NULL 表示没用上你建的任何二级索引。这两个信号出现一个，就说明索引被绕过了，不是没建好，是被评估后否决了。
-
rows接近表总行数（比如 100 万行的表，rows=923410），基本等于全扫，哪怕type是range或ref -
filtered值极低（如1.00），说明 WHERE 条件几乎没过滤能力，优化器自然不指望它 - 联合索引下
key_len比预期小很多，比如idx_a_b_c预期用满三层，但key_len只显示用了前两层，大概率中间某列因范围查询或类型不匹配被截断了
ANALYZE TABLE 不是可选项，是必做动作
Cardinality 是优化器估算成本的关键输入，但它不是精确值，而是采样估算结果，存在 information_schema.STATISTICS 表里。如果表经历过大批量导入、长期未更新，这个值可能严重失真——比如总行数 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高一截，所以选主键扫描，碰到第一条匹配就停
真正危险的是 rows 和 key_len 共同暴露的“假索引”
有些查询 type 看似正常（比如 ref），但 rows 高达几十万，key_len 又暗示只用了联合索引前半段——这说明索引形同虚设：它确实被“用上了”，但过滤效率极低，实际效果和全表扫描差不多。
这类问题最难排查，因为没报错、没警告，只有慢查询日志和 EXPLAIN 的数字在悄悄说话。盯住 rows 和 filtered 的组合，比只看 key 是否为空重要得多。
