列索引的有效性是否与列数据的熵有关

时间:2017-03-13 07:08:24

标签: mysql sql postgresql orm relational-database

作为消费者和偶尔的关系数据库(Postgres,MySQL),我经常需要在各种查询的上下文中考虑查询速度。但是,在生产数据库之前,您通常不知道数据库的使用方式或瓶颈可能存在的位置。

这让我想知道,我可以使用关于列的预测熵的经验法则作为猜测列的索引速度增加的启发式算法吗?

快速的Google会出现由计算机科学专业毕业生为计算机科学毕业生撰写的论文。对于一个自学成才的程序员,你能用“外行”的术语来概括吗?

熵?:我定义的熵是按行数除以平均重复值的次数计算的(平均值)。如果对于那些具有CS词汇量的人来说这是一个不好的选择,请提出一个更好的词。

2 个答案:

答案 0 :(得分:1)

我认为您要问的是索引对列中数据的数据分布的影响。这里有一堆理论。在GENERAL中,您会发现索引查找效率取决于索引中数据的分布。换句话说,如果你拉动表格的0.01%,那么索引的效率要高于拉动表格的5%。这是因为随机磁盘I / O总是效率低(即使在SSD上由于OS的预读缓存)也不如顺序读取。

现在这不是唯一的考虑因素。关于检索集合的最佳方法总是存在问题,特别是如果使用索引进行排序。您是否扫描订购索引或过滤索引然后排序?通常,您假设数据在两者之间均匀分布,但这是一个错误的假设,您可能会得到错误的查询计划。

所以你应该在这里做的是查找索引cardinality并获得查询计划的经验,特别是当计划程序出错时你才能理解为什么会出错。

答案 1 :(得分:1)

这个问题真的要广泛回答,但我会尝试总结一下PostgreSQL的情况(我对其他RDBMS知之甚少,但我写的一些内容将适用于大多数)。

而不是上面提到的 entropy ,PostgreSQL术语是某个条件的 selective ,它是0到1之间的数字,定义为数字满足条件的行除以表中的总行数。具有低选择性值的条件(有点违反直觉)称为高选择性

确定索引是否有用的唯一可靠方法是比较使用和不使用索引的执行时间。

当PostgreSQL决定对表上的条件使用索引是否有效时,它会将整个表的顺序扫描的估计成本与使用索引扫描的成本进行比较适用指数。

由于顺序读取和随机I / O(用于访问索引)的速度通常不同,因此有一些参数会影响成本估算,从而影响决策:

  • seq_page_cost:按顺序提取的磁盘页面的费用
  • random_page_cost:非连续获取磁盘页面的费用
  • cpu_tuple_cost:处理一个表格行的费用
  • cpu_index_tuple_cost:索引扫描期间处理索引条目的成本

这些成本以虚数单位衡量,习惯上将seq_page_cost定义为1,将其他成本定义为关联。

数据库收集表统计信息,以便它知道每个表的大小以及列值的分布方式(最常见的值及其频率,直方图,与物理位置的相关性)。

要查看PostgreSQL如何使用所有这些数字的示例,请查看文档中的this example

使用默认设置,经验法则可能是,除非选择性小于0.2,否则索引不会有太大帮助。