MySQL优化器基于统计信息估算I/O页数与CPU行数，以随机磁盘页读（16KB）为1.0成本基准，加权计算总cost；核心依赖Cardinality等采样统计，失真则成本误判。
MySQL优化器怎么用统计信息算成本
它不靠直觉，也不穷举所有路径，而是把每个候选计划拆成“读多少页+算多少行”的数学题。核心是把 I/O 和 CPU 操作都折算成统一单位：以一次随机磁盘页读（16KB）为 1.0 成本基准。
比如 SELECT * FROM t WHERE a = 1 AND b > 100，优化器会分别估算：
- 全表扫描：≈
data_page_count（数据页数） +table_rows × 0.1（每行谓词求值） - 走
INDEX(a, b)：≈btree_height（定位根到叶） +index_range_pages（索引区间页） +rows_matched × 0.1（过滤计算） +rows_matched × 1.0（回表，按随机 IO 算）
注意：这里的 rows_matched 不是你查出来的行数，而是从 innodb_index_stats.n_diff_pfx01 等统计字段推算出的基数（cardinality），它直接影响“走索引是否划算”的判断。
统计信息不准时，成本就全是错的
InnoDB 默认对每张表随机采样 20 个数据页来估算索引唯一值数量（n_diff_pfxNN）。如果表有严重数据倾斜——比如 95% 的 status 值是 'active'，剩下 5% 分散在几十种状态里——那采样结果可能把 'active' 的基数估低一个数量级，导致优化器误判 WHERE status = 'active' 选择性差，放弃走索引。
常见表现：
-
EXPLAIN显示type=ALL，key=NULL，但明明有索引 - 同一条 SQL 在不同时间执行，
EXPLAIN结果突变（尤其在大批量UPDATE或TRUNCATE后） -
rows字段和实际扫描行数偏差超过 5 倍
这时不是 SQL 写得有问题，而是统计信息过期了。手动触发 ANALYZE TABLE t 是最直接的修复方式；若列分布极不均匀，再补上直方图：ANALYZE TABLE t UPDATE HISTOGRAM ON status WITH 64 BUCKETS。
为什么 EXPLAIN 的 rows 和真实扫描数差很远
rows 是优化器基于统计信息“猜”出来的预估行数，不是执行时的实际值。它只参与成本计算，不控制执行逻辑。所以即使 rows=100，实际执行时扫描了 10 万行，只要成本模型认为这个路径总开销最低，它就敢选。
影响 rows 准确性的关键点：
- 联合索引中，只有最左前缀匹配的列才贡献
n_diff_pfxNN统计；INDEX(a, b, c)上WHERE b = ?无法利用该统计，rows可能直接按整表行数 × 0.1 估算 -
filtered字段代表条件过滤率，MySQL 5.7 之前靠固定经验值（如LIKE '%x'固定按 12.5%），8.0 后依赖直方图或更精细的采样 - 没有持久化统计（
innodb_stats_persistent=OFF）时，每次重启 MySQL 都会重采样，冷启动后首次查询容易选错计划
查看和验证统计信息来源的命令
别只盯着 EXPLAIN，要下钻到统计本身：
- 看索引基数：
SHOW INDEX FROM t中的Cardinality列（注意：这是采样估算值，非精确） - 查持久化统计表：
SELECT * FROM mysql.innodb_index_stats WHERE table_name = 't'，重点看n_diff_pfx01、n_leaf_pages、size - 检查直方图是否存在：
SELECT * FROM information_schema.COLUMN_STATISTICS WHERE table_name = 't' - 确认是否启用自动重算：
SELECT @@innodb_stats_auto_recalc, @@innodb_stats_persistent
真正难的不是看懂这些数字，而是在业务低峰期判断要不要跑 ANALYZE TABLE——它会加 READ ONLY 锁，且若表被长事务持有，会卡住直到事务结束。线上大表务必提前评估锁等待风险。
