MySQL优化器通过cost_model估算I/O和CPU成本来选择执行计划，关键在于索引访问的总开销（如回表次数、排序需求）是否低于聚簇索引顺序扫描；例如idx_source_id因回表随机IO多、无法利用ORDER BY id且选择性低，导致其成本高于PRIMARY索引扫描。
MySQL优化器怎么算“走索引 vs 全表扫描”的成本
MySQL不会凭感觉选执行计划，它靠cost_model估算每种访问路径的I/O和CPU开销。关键不是“有没有索引”，而是“用这个索引要读多少页、回几次表、排序是否能复用”。比如你写了WHERE source_type = 9401003 AND source_id = '1814613774586351713' ORDER BY id ASC LIMIT 1，优化器发现：idx_source_id是(source_id, source_type, state)，但WHERE里source_id是等值、source_type也是等值——看起来能用上；可问题在于，这个索引的顺序是source_id在前，而你的source_id值分布极广（比如千万级唯一值），导致索引定位后仍要扫描大量叶子节点才能凑够LIMIT 1所需的结果，再加上ORDER BY id无法利用该索引排序，还得额外排序或逐条比对。这时候它可能判定：不如直接走主键聚簇索引，按id顺序扫，碰到第一个匹配就停——实际反而更快。
为什么idx_source_id没被选中，却用了PRIMARY
根本原因在于二级索引+回表的总成本超过了全表扫描（准确说是“聚簇索引扫描”）的成本。注意：InnoDB里没有真正意义的“全表扫描”，所谓全表扫描本质是遍历聚簇索引叶子节点。而idx_source_id是非聚簇索引，它的叶子节点只存source_id、source_type、state和主键id。你要SELECT *，就必须回表；而回表是随机IO——每拿到一个id，就要跳去聚簇索引另一位置取整行。如果预估要回表3次以上，成本就很容易超过顺序扫描聚簇索引几页。
- 你的
source_id是varchar(64)，长度大、比较慢，且索引前导列是source_id，但查询条件中它的选择性未必高（比如很多记录source_id相似前缀） -
idx_source_id未包含update_time或state以外的字段，SELECT *必然触发回表 -
ORDER BY id无法利用idx_source_id，因为id不在索引中且不连续，优化器无法保证先扫到的那条就是LIMIT 1要的
如何验证和干预这个成本判断
别猜，用EXPLAIN FORMAT=JSON看真实评估数据。重点关注query_cost、used_columns、range_analysis里的analyzing_range_alternatives和rows_for_plan。你会看到优化器其实试了idx_source_id，但算出来成本比PRIMARY高一截。
- 强制走索引？可用
USE INDEX(idx_source_id)，但只是绕过优化器，不解决根本问题 - 改写查询：如果业务只要1条，且
id是自增，可考虑去掉ORDER BY id，或改用WHERE ... AND id > ?配合应用层分页 - 调整索引：把
id加进idx_source_id末尾变成(source_id, source_type, state, id)，虽不能避免回表，但能让ORDER BY id天然有序，减少排序开销 - 覆盖索引：如果只需部分字段，比如只要
id和state，建INDEX idx_cover (source_id, source_type, state, id)，就能避免回表
容易被忽略的隐性成本点
很多人只盯着“能不能走索引”，却漏掉三个隐形杀手：
-
WHERE中字段的collation和参数类型不一致，比如source_id是utf8mb4_bin，但传参是utf8mb4_general_ci，会隐式转换，使索引失效 - 统计信息过期：
ANALYZE TABLE mapping_filter_record没跑过，优化器基于错误的行数/分布估算成本 -
LIMIT 1在高偏移场景下毫无帮助——优化器无法预知“第一个匹配在哪”，仍得按最坏情况估算扫描量
真正的瓶颈往往不在SQL写法本身，而在优化器看到的“数据画像”是否准确。查INFORMATION_SCHEMA.STATISTICS确认索引列顺序，跑ANALYZE TABLE更新统计，再看FORMAT=JSON输出，才能看清它到底为什么放弃那个你以为“完美匹配”的索引。
