天天看点

mysql为什么选错索引?怎么解决?

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 来强行指定索引,也可以通过修改语句来引导优化器,还可以通过增加或者删除索引来绕过这个问题。