全表扫描成本通过预估逻辑页数计算，而非实际执行：io_cost = (data_length / 16384) × 1.0 + 1.1，cpu_cost = rows × 0.2 + 1.0；其中data_length为b+树叶子节点总字节数，rows为innodb估算行数，二者均来自统计信息，再结合buffer pool命中率等隐含因素微调最终read_cost。
全表扫描成本怎么算：不是扫一遍，而是预估逻辑页数
MySQL优化器从不真正执行一次全表扫描来测速，它靠的是Data_length和rows这两个统计值做静态估算。核心公式就两条：
-
IO_cost = (Data_length / 16384) * 1.0 + 1.1—— 先把数据长度转成聚簇索引页数（InnoDB默认页大小16KB），再乘以每页读取成本常数1.0 -
CPU_cost = rows * 0.2 + 1.0—— 每行过滤、比较、构造结果的成本按0.2计，不是实测，是模型假设
注意：rows来自SHOW TABLE STATUS，InnoDB下只是估算值；Data_length也不是磁盘真实占用，而是B+树叶子节点总字节数。页数算出来后，优化器会进一步结合Buffer Pool命中率、MVCC版本链长度等隐含因素微调——但这些不暴露给用户，只影响最终read_cost。
索引查找成本怎么算：回表次数才是关键变量
走索引不等于快，尤其当要回表时。优化器真正盯住的是「预计回表次数」，而不是索引本身是否存在。它用Cardinality除以rows估算单值选择性，再乘以匹配行数得到回表次数：
- 若
EXPLAIN中key显示用了idx_source_id，但Extra里没Using index，说明必然回表 - 回表一次 ≈ 随机IO，成本按
3～5倍顺序读一页计算；而聚簇索引顺序扫描一页能读几十行 -
optimizer_trace里看"read_cost"字段，如果索引路径的read_cost远高于全表扫描的read_cost，基本就是回表开销压垮了优势
比如WHERE source_id = 'x'匹配1行，但Cardinality被低估为2000，优化器就会按2000次回表估算，直接放弃索引。
为什么rows很小却选了ALL：代价模型不认“行数”，只认“页+CPU”
rows只是中间估算值，不是决策依据。优化器比的是总成本：read_cost + eval_cost + prefix_cost。常见误判场景：
- 查询带
ORDER BY id LIMIT 1，但id不在索引里 → 优化器知道必须先捞出所有匹配行再排序，eval_cost爆炸 - 用了
SELECT *，索引只覆盖部分列 → 强制回表，read_cost翻倍 -
innodb_stats_persistent = OFF且长期没ANALYZE TABLE→Cardinality严重失真，rows失去参考价值 - 小表（如500行）且
innodb_buffer_pool已缓存全部页 → 全表扫描实际无磁盘IO，而索引B+树根节点可能还在磁盘上，随机读反而更慢
别盯着possible_keys非空就以为该走索引——key为空才说明优化器算过，发现它更贵。
怎么验证优化器到底怎么想：别猜，直接看optimizer_trace
唯一能看清成本拆解的方式，就是打开optimizer_trace：
SET optimizer_trace="enabled=on"; SELECT ...; SELECT * FROM INFORMATION_SCHEMA.OPTIMIZER_TRACE;- 重点看
"considered_execution_plans"数组里每条路径的"cost_for_plan"，以及各子项："read_cost"（页读）、"eval_cost"（行过滤）、"prefix_cost"（排序/连接附加开销） - 如果某索引路径的
"eval_cost"占总成本90%以上，说明不是索引不行，是条件过滤太粗（比如status != 'done'匹配80%行），得换条件或建直方图
真正容易被忽略的，是优化器对“提前终止”的敏感度：LIMIT 1会让它极度偏好能最早停下来的路径，哪怕这条路径理论总行数更多——顺序扫主键遇到第一行就返回，而索引+回表必须做完全部步骤才能确认结果。
