只读数据库上的索引

Question

我不确定这是否是这个问题的地方，但这里是：

我有一个只读数据库，它包含许多使用c＃桌面应用程序访问和搜索的表。

我正在查看索引，大多数教程和有关索引的信息都集中在SELECT性能和INSERT / UPDATE性能与引入索引之间的权衡。

我的问题是，对于只读数据库，将索引放在每列和每个列的组合上会有什么缺点？（假设我也不太关心数据库的大小？）

或换句话说，你可以＆＃34; Over Index＆＃34;只读数据库？

Answer 1

实际上，iirc是一个特定于仓库的系统，SybaseIQ就是这样做的 - 将每个字段放在自己的索引中。但我不喜欢这个想法。我非常怀疑这个想法，如果那里的东西是个好主意，那到处都是个好主意。我称之为 Tomm Carr普遍规则，适用于所有情况下所有情况或简称TCUR。

这是：

  

除了Tomm Carr   普遍规则适用于所有情况下的所有情况   在所有情况下，没有一条适用的规则   在所有情况下所有条件下的所有情况。

这仅仅意味着我们可以开发的最佳规则，标准或默认值绝不仅仅是一个良好的开端。

因此，如果您想设计最好的仓库，您将不得不投入工作。现在，这是一个仓库，这意味着您可以比在OLTP系统中更容易使用索引。但更多并没有转化为＆＃34;无缘无故地抛出它们。＆＃34;

分析查询。从最常用到最不常用的排序。有些仅用于每月，每季度或每年生成的报告。你几乎可以忘记那些 - 即使你可以将执行时间从十分钟减少到十秒......它可能不值得付出努力。

调整系统以查找最常执行的查询。然后在不影响第一组的情况下尽可能少地进行调整。

哦，如果可以的话，还可以用一个词来覆盖索引。通常，我们会告诉您查看查询提到的每个字段：

select  a, b, c
from    table
where   e = f
    and g > something;

然后覆盖索引将包含字段a，b，c，e，f和g。

不一定是个好主意，或者至少不一定是最佳主意。考虑到过滤可能涉及数百，数千或数百万条记录，然后才能得到非常小或甚至单一的结果。在使用e，f和g进行所有过滤时，没有理由在包含字段a，b和c的索引周围进行混洗。这里最好的设计是两个覆盖指数：一个带有a，b，c，另一个带有e，f，g。称它们为结果索引和过滤索引。因此，使用较小的行（每个I / O更多的行）执行过滤，并且当完成所有工作时，然后转到结果索引以获得更少的答案。

但请不要忘记TCUR也适用于此。只有通过良好，全面的分析才能告诉您要走哪条路。

Answer 2

让我们考虑一下在索引表中插入/更新行时会发生什么（让我们假设我们使用的是标准B树索引）。该条目将添加到表本身以及表中每个索引中的条目。是什么造成了时间/空间开销。

直接回答你的问题，在生成索引的初始时间/空间开销之外，在每个表的每一列上放置索引没有重大缺点。请记住，当您执行查询时，每个表最多只能使用一个索引。通过拥有大量索引/复合索引，您可以在决定使用哪些索引时为优化器提供最佳选择。

话虽如此，开始生成任意索引时很烦人。如果我是你，我会查看你需要哪些查询才能更快地运行并开始相应地生成索引。