第十讲 MySQL为什么有时候会选错索引？

在 MySQL 中，索引选择由优化器负责，其目标是以最小代价执行语句，但有时会选错索引，导致执行速度变慢。

建表与数据插入
- 创建表t，包含id、a、b字段，分别建立主键索引和a、b字段的普通索引。
- 使用存储过程插入 10 万行数据，取值按整数递增。
初始查询情况
- 执行select * from t where a between 10000 and 20000;，优化器选择索引a，扫描行数 10001 行，执行情况符合预期。
数据变更后的问题
- 在session A开启事务，session B删除数据后重新插入 10 万行数据。
- 此时session B再次执行上述查询，未选择索引a，而是走了全表扫描，扫描 10 万行，执行时间 40 毫秒。而使用force index(a)强制使用索引a时，扫描 10001 行，执行 21 毫秒。
原因分析
- MySQL 通过索引的 “区分度”（基数）估算扫描行数，基数越大区分度越好，但采样统计方法导致基数不准。
- 优化器预估使用索引a时每次从索引a取值后要回主键索引查整行数据，计算代价后认为直接扫描主键索引更快，然而实际执行时间表明此选择并非最优。

查询语句
- select * from t where (a between 1 and 1000) and (b between 50000 and 100000) order by b limit 1;
预期与实际索引选择
- 从条件分析使用索引a扫描行数少应更快，但优化器选择了索引b，扫描行数预估为 50198 行。
原因分析
- 优化器认为使用索引b可避免排序（b本身有序），即使扫描行数多也判定代价更小。

例如将order by b limit 1改为order by b,a limit 1，使扫描行数成为影响决策的主要条件，诱导优化器选择索引a。但这种修改需根据数据特征和语句逻辑，不具备通用性。

索引统计方式
- MySQL 采用采样统计方法，InnoDB 默认选择N个数据页统计不同值取平均值后乘以索引页面数得到基数。当变更数据行数超过1/M时自动触发重新统计。
- 可通过设置innodb_stats_persistent参数选择统计信息存储方式，on表示持久化存储，默认N = 20，M = 10；off表示只存储在内存中，默认N = 8，M = 16。
解决索引统计不准确问题
- 使用analyze table命令重新统计索引信息，可解决因索引统计不准确导致的优化器选错索引问题，但优化器还会综合其他因素判断。