索引的选择

    本章节将介绍 TiDB 如何选择索引去读入数据，以及相关的一些控制索引选择的方式。

    在介绍索引的选择之前，首先要了解 TiDB 有哪些读表的方式，这些方式的触发条件是什么，不同方式有什么区别，各有什么优劣。

    TiDB 在选择索引时，会基于每个读表算子的代价估算，在此基础上提供了启发式规则 “Skyline-Pruning”，以降低错误估算导致选错索引的概率。

    Skyline-Pruning 是一个针对索引的启发式过滤规则，评判一个索引的好坏需要从以下三个维度进行衡量：

    • 选择该索引是否能满足一定的顺序。因为索引的读取可以保证某些列集合的顺序，所以满足查询要求顺序的索引在这个维度上优于不满足的索引。

    • 索引的列涵盖了多少访问条件。“访问条件”指的是可以转化为某列范围的 where 条件，如果某个索引的列集合涵盖的访问条件越多，那么它在这个维度上更优。

    对于这三种维度，如果某个索引 idx_a 在三个维度上都不比 差，且有一个维度比 idx_b 好，那么就会优先选择 idx_a。

    在使用 Skyline-Pruning 规则排除了不合适的索引之后，索引的选择完全基于代价估算，读表的代价估算需要考虑以下几个方面：

    • 索引的每行数据在存储层的平均长度。
    • 索引的回表代价。
    • 索引查询时的范围数量。

    根据这些因子和代价模型，优化器会选择一个代价最低的索引进行读表。

    代价选择调优的常见问题

    1. 估算的行数量不准确？

    2. 统计信息准确，为什么读 TiFlash 更快，而优化器选择了 TiKV？

      目前区别 TiFlash 和 TiKV 的代价模型还比较粗糙，可以调小 tidb_opt_seek_factor 的值，让优化器倾向于选择 TiFlash。

    3. 统计信息准确，某个索引要回表，但是它比另一个不用回表的索引实际执行更快，为什么选择了不用回表的索引？

      碰到这种情况，可能是代价估算时对于回表的代价计算得过大，可以调小 tidb_opt_network_factor，降低回表的代价。

    通过 可以实现单条查询对索引选择的控制。