我正在一个具有相当大的Oracle数据库的项目中工作（尽管我的问题同样适用于其他数据库）。我们有一个Web界面，允许用户搜索几乎任何可能的字段组合。
为了使这些搜索快速进行，我们将索引添加到我们认为用户通常会在其上进行搜索的字段和字段组合。但是，由于我们并不真正了解客户将如何使用该软件，因此很难确定要创建哪些索引。
空间不是问题；我们有一个4 TB的RAID驱动器，我们只使用其中的一小部分。但是，我担心索引过多会导致性能下降。因为每次添加，删除或修改行时都需要更新这些索引，所以我认为在一个表上包含数十个索引是一个坏主意。
那么多少索引被认为太多呢？10个？25吗 50吗 还是我应该只介绍真正，非常普遍和显而易见的案例，而忽略其他所有内容？
Answers:
这取决于表上发生的操作。
如果有很多SELECT且更改很少，请对所有您喜欢的内容进行索引....（可能）加快SELECT语句的速度。
如果该表受到UPDATE，INSERT + DELETE的严重打击，那么使用大量索引的速度将非常慢，因为每次执行这些操作之一时都需要修改它们
话虽如此，您可以清楚地向表添加很多毫无意义的索引，这些索引什么也没做。将B-Tree索引添加到具有2个不同值的列中将毫无意义，因为它在查找数据方面不会增加任何内容。列中的值越独特，则从索引中受益越多。
其他人一直在给您很好的建议。在您前进的过程中，我还有其他建议。在某些时候，您必须决定最佳的索引编制策略。最后，最好的PLANNED索引策略仍然可以最终创建不会被使用的索引。一种可以让您查找未使用的索引的策略是监视索引使用情况。您可以按照以下步骤进行：
alter index my_index_name monitoring usage;然后，可以通过查询v $ object_usage监视从那时起是否使用索引。有关此信息，请参见《Oracle®数据库管理员指南》。
只需记住，如果您有一种在更新表之前先删除索引然后重新创建它们的仓储策略，则必须将索引设置为再次进行监视，并且将丢失该索引的所有监视历史记录。
在数据仓库中，拥有大量索引是很常见的。我使用的事实表有两百列，其中有190个已建立索引。
尽管这样做有开销，但必须从上下文中了解到，在数据仓库中，我们通常只插入一次行，但我们从不对其进行更新，但是它可以参与数千个SELECT查询，这可能会受益于对任何列。
为了获得最大的灵活性，数据仓库通常使用单列位图索引，但在高基数列上则可以使用（压缩的）btree索引。
索引维护的开销通常与写入大量块的开销有关，并且随着新行的添加，该块拆分时添加的值位于该列的现有值范围的“中间”。可以通过分区并使新数据负载与分区方案对齐，以及使用直接路径插入来缓解这种情况。
为了更直接地解决您的问题，我认为首先对显而易见的内容建立索引可能很好，但是不要害怕针对该表的查询是否会增加更多的索引。
在关于爱因斯坦的简单描述中，可以根据需要添加任意多个索引，而不必添加更多索引。
但是，严重的是，每当将数据添加到表时，添加的每个索引都需要维护。在主要是只读的表上，很多索引是一件好事。在高度动态的表上，越少越好。
我的建议是讲解常见和显而易见的情况，然后，当您遇到需要从特定表中获取数据的速度更快的问题时，请评估并添加索引。
另外，最好每隔几个月重新评估索引编制方案，以查看是否有需要索引的新内容或已创建的索引未用于任何用途，因此应将其删除。
除了其他所有人提出的要点外，如果存在更多索引，则基于成本的优化器还会在为SQL语句创建计划时产生成本，因为要考虑的组合更多。您可以通过正确使用绑定变量来减少这种情况，以使SQL语句保留在SQL缓存中。然后，Oracle可以进行软解析并重新使用上次发现的计划。
与往常一样，没有什么是简单的。如果涉及倾斜的列和直方图，那么这可能是个坏主意。
在我们的Web应用程序中，我们倾向于限制我们允许的搜索组合。否则，您必须逐字测试每种组合的性能，以确保您不会遇到某个人会发现某天的潜伏问题。我们还实施了资源限制，以防止在出现问题时在应用程序中的其他地方引起问题。
我对真实的项目和真实的MySql数据库进行了一些简单的测试。我已经在以下主题中回答了：为多个数据库列建立索引的成本是多少？
但是我认为如果在这里引用它会更好：
我使用真实的项目和真实的MySql数据库进行了一些简单的测试。
我的结果是：将平均索引（索引中的1-3列）添加到表中-使插入速度降低2.1％。因此，如果添加20个索引，则插入速度将降低40-50％。但是您的选择将快10-100倍。
那么可以添加许多索引吗？-取决于:)我给了我我的结果-您决定！
我认为没有静态答案，这种情况属于“性能调整”范畴。
可能是您的应用程序执行的所有操作都由主键查找，也可能是相反的，查询是在无限制的字段组合上完成的，尤其是在给定的任何时间都可以使用。
除了索引之外，还对数据库进行了重新粒度化，以包括计算出的搜索字段，拆分表等-它实际上取决于您的负载形状和查询参数，一个查询需要“真正”恢复多少/什么数据。
如果您的整个数据库都以存储过程外观为前导，则转弯会变得容易一些，因为您不必担心每个临时查询。或者，您可能对将要命中数据库的查询类型有深刻的了解，并且可以将调整限制在这些查询上。
对于SQL Server，我发现数据库引擎优化顾问非常有用-您设置了“典型”工作负载，它可以为添加/删除索引和统计信息提供建议。我确信其他数据库有类似的工具，无论是“官方”还是第三方。
这确实是一个比实际问题更多的理论问题。索引对性能的影响取决于所拥有的硬件，Oracle的版本，索引类型等。昨天，我听说Oracle宣布了一种由HP生产的专用存储，该存储在11g数据库中的运行速度应提高10倍。对于您的情况，可以有几种解决方案：1.拥有大量索引（> 20）并每天（每晚）重建它们。如果表每天有成千上万的更新/删除，这将特别有用。2.对表进行分区（如果适用于您的数据模型）。3.使用单独的表存储新的/更新的数据，并运行一个每晚将数据组合在一起的过程。这将需要更改您的应用程序逻辑。4.如果您的数据支持，请切换到IOT（索引组织表）。
对于这种情况，当然可能会有更多解决方案。我对您的第一个建议是将数据库克隆到开发环境中，并对它进行一些压力测试。
真正的原因是，不要添加索引，除非您知道（并且这通常意味着收集使用情况统计信息）它的使用频率远比更新的频率高。
任何不符合该标准的索引将比在不习惯使用索引的情况下要付出的性能损失要多得多。
Sql server为您提供了一些很好的工具，可让您查看实际使用的索引。本文http://www.mssqltips.com/tip.asp?tip=1239给出了一些查询，使您可以更好地了解索引的使用量，而不是索引的更新量。