正文

mysql为什么选错索引？

在进行慢SQL分析的时候，有时候我们会发现explain的扫描行数和慢日志中的行数相差很大，那explain中的rows这个扫描行数是怎么判断的？

 其实MySQL在真正开始执行语句之前，并不能精确的满足这个条件的记录有多少行，而只能根据统计信息来估算记录数。

 这个统计信息就是索引的“区分度”，显然，一个索引上不同的值越多，这个索引的区分度就越好。而一个索引上不同的值的个数，我们称之为“基数”（cardinality)。也就是说，这个基数越高，索引的区分度越好。

 日常中我们可以通过”show index from tablename”看到一个索引的基数。

MySQL怎样得到索引基数？

 Mysql是通过采样统计的方法。为什么要采样统计呢？因为把整张表取出来一行行统计，虽然可以得到精确的结果，但是代价太高了，所以只能选择“采样统计”。

 采样统计的时候，InnoDB默认会选择N个数据页，统计这些页面上的不同值，得到一个平均值，然后乘以这个索引的页面数，就得到了这个索引的基数。

 而数据表是会持续更新的，索引统计信息也不会固定不变。所以，当变更的数据行数超过1/M的时候，会自动触发重新做一次索引统计。

 在MySQL中，有两种存储索引的方式，可以通过设置参数innodb_stats_persistent的值来选择：

 当设置为on的时候，表示统计信息会持久化存储。这时，默认的N是20,M是10.

 设置为off的时候，表示统计信息只存储在内存中。这时，默认的N是8，M是16.

 由于是采样统计，所以不管N是20还是8，这个基数都是很不准确的。

索引选择异常处理办法

采用force index 强行选择一个索引。

修改sql语句、引导MySQL使用我们期望的索引。

在有些场景下，我们可以新建一个更适合的索引，来提供给优化器做选择，或删除掉误用的索引。

由于索引统计信息的不准确，可以用analyze table来解决。

而对于其它优化器误判断的情况，你可以在应用端用force index 来强行指定索引，也可以通过修改语句来引导优化器，还可以通过增加或者删除索引来绕过这个问题。