02.11 Day 23 - 如何选择索引

大家好，我是 Snow Hide，作为《MySQL 实战》这个专栏的学员之一，这是我打卡的第 23 天，也是我第 81 次进行这种操作。

今天我温习了该专栏里一篇叫《MySQL 为什么有时候会选错索引？》的文章。

关键词总结：优化器逻辑（最优执行方案、综合判断、判断扫描行数、获得索引基数、两种存储索引统计的方式）、索引选择异常和处理（采用 force index 强行选择一个索引、引导 MySQL 使用我们期望的索引、新建一个更合适的索引，供优化器做选择，或删掉误用的索引）。

 

所学总结：

 

优化器逻辑

最优执行方案

优化器选择索引的目的是找到最有执行方案，并用最小的代价去执行语句。

综合判断

扫描行数并不是唯一的判断标准，优化器还会结合是否使用临时表、是否排序等因素进行综合判断。

判断扫描行数

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

获得索引基数

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

两种存储索引统计的方式

• 设置为 on 的时候，表示统计信息会持久化存储。这时，默认的 N 是 20，M 是 10；
• 设置为 off 的时候，表示统计信息只存储在内存中。这时，默认的 N 是 8，M 是 16。
   

索引选择异常和处理

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

MySQL 会根据词法解析的结果分析出可能可以使用的索引作为后选项，然后在候选列表中依次判断每个索引需要扫描多少行。如果 force index 指定的索引在候选索引列表中，就直接选择该索引，不再评估其他索引的执行代价。

引导 MySQL 使用我们期望的索引

这种根据数据特征来诱导优化器的做法不具备通用性。

新建一个更合适的索引，供优化器做选择，或删掉误用的索引

找到一个更合适的索引一般比较难。删掉优化器错误选择的索引，使其重新选择正确的索引。

 

末了

重新总结了一下文中提到的内容：索引统计的更新机制、优化器存在选错索引的可能性、索引统计信息不准确导致的问题、在应用端用 force index 来强行指定索引。