有多少数据库索引是太多了？
我正在处理一个具有相当大的Oracle数据库的项目(尽管我的问题同样适用于其他数据库)。我们有一个web界面，允许用户搜索几乎任何可能的字段组合。
为了使这些搜索速度更快，我们为我们认为用户通常会搜索的字段和字段组合添加索引。然而，由于我们不知道我们的客户将如何使用这个软件，所以很难判断要创建哪些索引。
空间不是问题；我们有一个4TB的RAID驱动器，我们只使用了其中的一小部分。但是，我担心索引过多可能带来的性能损失。因为每次添加、删除或修改一行时都需要更新这些索引，所以我认为在一个表上有几十个索引不是一个好主意。
那么多少索引被认为太多了? 10? 25? 50？或者我应该只涵盖真正、非常常见和明显的情况，而忽略其他所有的情况？
回答 15
Stack Overflow用户
发布于 2008-09-26 18:52:54
这取决于在表上发生的操作。
如果有很多选择，只有很少的更改，那么索引所有你喜欢的……这些将(潜在地)加速SELECT语句。
如果表受到更新的严重影响，则插入+删除...使用大量索引时，这些操作将非常慢，因为每次执行其中一个操作时，都需要对它们进行修改
话虽如此，您可以清楚地将许多毫无意义的索引添加到不会做任何事情的表中。将B-Tree索引添加到具有两个不同值的列是没有意义的，因为它不会添加任何数据查找方面的内容。列中的值越唯一，它将从索引中获益越多。
Stack Overflow用户
发布于 2008-09-26 21:41:11
其他人都给了你很好的建议。随着你的进步，我有一个额外的建议给你。在某些时候，你必须决定你最好的索引策略。最后，即使是最好的计划索引策略，也可能最终创建不会被使用的索引。让您查找未使用的索引的一种策略是监视索引使用情况。您可以执行以下操作：-
alter index my_index_name monitoring usage;然后，您可以通过查询v$object_usage来监视该索引是否被使用。有关这方面的信息可以在Oracle® Database Administrator's Guide中找到。
请记住，如果您有一个仓库策略，即在更新表之前删除索引，然后重新创建它们，那么您将不得不再次设置索引以进行监视，并且您将丢失该索引的所有监视历史记录。
Stack Overflow用户
发布于 2008-09-26 19:37:22
在数据仓库中，拥有大量索引是很常见的。我处理过有200列的事实数据表，其中190列已建立索引。
尽管这会带来一些开销，但必须在上下文中理解的是，在数据仓库中，我们通常只插入一行一次，我们永远不会更新它，但是它可以参与数千个SELECT查询，这些查询可能受益于对任何列的索引。
为了获得最大的灵活性，数据仓库通常使用单列位图索引，但在高基数列上除外，其中可以使用(压缩的) btree索引。
索引维护的开销主要与写入大量块和块拆分的开销有关，因为新行被添加到该列的现有值范围的“中间”。这可以通过分区并使新数据负载与分区方案对齐，以及通过使用直接路径插入来缓解。
为了更直接地解决您的问题，我认为一开始对显而易见的内容进行索引可能是很好的，但如果对表的查询将受益，请不要害怕添加更多的索引。
https://stackoverflow.com/questions/141232
复制相似问题