Database 有多少数据库索引太多？

我正在从事一个拥有相当大的Oracle数据库的项目（尽管我的问题同样适用于其他数据库）。我们有一个web界面，允许用户搜索几乎任何可能的字段组合

为了让这些搜索快速进行，我们正在为我们认为用户通常会搜索的字段和字段组合添加索引。但是，由于我们不知道客户将如何使用该软件，因此很难确定要创建哪些索引

空间不是问题；我们有一个4 TB的RAID驱动器，我们只使用其中的一小部分。但是，我担心索引过多可能会带来性能损失。因为每次添加、删除或修改一行时都需要更新这些索引，所以我认为在一个表上有几十个索引是个坏主意

---

那么，有多少索引被认为太多了？10? 25? 50? 或者我应该只讨论真正、非常常见和明显的情况，而忽略其他所有情况吗？

这取决于表中发生的操作

如果有很多选择和很少的变化，索引所有你喜欢的。。。。这些将（潜在地）加快SELECT语句的速度

如果表被更新严重影响，INSERTs+DELETEs。。。由于每次执行这些操作时都需要修改索引，因此使用大量索引会非常慢

---

话虽如此，您可以清楚地向一个表添加许多毫无意义的索引，而这些索引不会做任何事情。将B树索引添加到具有两个不同值的列将是毫无意义的，因为它不会在查找数据方面添加任何内容。列中的值越独特，它就越能从索引中受益。

最终需要多少索引取决于数据库服务器上应用程序的行为

一般来说，插入的次数越多，索引就变得越痛苦。每次插入时，都必须更新包含该表的所有索引

---

现在，如果您的应用程序具有相当多的读取量，或者如果几乎全部读取，则索引是一种可行的方法，因为只需很少的成本就可以大大提高性能。

如果您主要进行读取（并且很少进行更新），那么就没有理由不索引需要索引的所有内容。如果您经常更新，那么您可能需要注意索引的数量。没有硬性数字，但当事情开始放缓时，你会注意到。确保您的聚集索引是基于数据的最有意义的索引。

有多少列？

---

我一直被告知要建立单列索引，而不是多列索引。因此，没有比列的数量更多的索引，IMHO.

< P>你可以考虑的一个事情是建立索引，以搜索的标准组合为目标。如果通常搜索column1，column2经常与之一起使用，column3有时与column2和column1一起使用，那么column1、column2和column3上按此顺序的索引可以用于这三种情况中的任何一种，尽管它只是需要维护的一个索引。

归根结底是，不要添加索引，除非您知道（这通常意味着收集使用情况统计数据），它的使用频率将远远高于更新的频率

任何不符合该标准的索引重建的成本都将高于在使用该索引的奇数情况下不使用该索引的性能损失

用一句关于简单性的话来说，添加所需数量的索引，不要再添加了

但是，严肃地说，每当数据添加到表中时，您添加的每个索引都需要维护。在主要为只读的表上，大量索引是一件好事。在高度动态的表上，越少越好

我的建议是涵盖常见和明显的情况，然后，当您遇到需要更快地从特定表中获取数据的问题时，评估并添加索引

---

另外，每隔几个月重新评估一次索引方案也是一个好主意，只是为了看看是否有什么新的索引需要索引，或者您创建的任何索引没有用于任何用途，应该被删除。

我认为没有静态的答案，这类事情属于“性能调整”

可能是你的应用程序所做的一切都是通过一个主键来查找的，也可能是一个oposite，因为查询是在未经分配的字段组合上完成的，任何特定的字段都可以在任何给定的时间使用

除了索引，还可以重新授权数据库以包含计算的搜索字段、拆分表等，这实际上取决于负载形状和查询参数，以及查询“真正”需要检索多少/哪些数据

如果您的整个数据库前面都是存储过程facades，那么转换会变得更容易一些，因为您不必担心每个临时查询。或者，您可能对影响数据库的查询类型有着深刻的理解，并且可以将调优限制在这些查询上

---

对于SQL Server，我发现数据库引擎优化顾问非常有用—您可以设置“典型”工作负载，它可以就添加/删除索引和统计信息提出建议。我相信其他DBs也有类似的工具，无论是“官方”还是第三方。

这确实是一个理论问题，而不是实际问题。索引对性能的影响取决于您拥有的硬件、Oracle的版本、索引类型等。昨天我听说Oracle宣布了一款由HP制造的专用存储设备，该设备在使用11g数据库时的性能应提高10倍。 对于您的情况，可以有几种解决方案： 1.拥有大量索引（>20）并每天（每晚）重建它们。如果表每天都有数千次更新/删除，这将特别有用。 2.对表进行分区（如果这适用于数据模型）。 3.使用分隔符

alter index my_index_name monitoring usage;