有多少数据库索引太多?

内容来源于 Stack Overflow,并遵循CC BY-SA 3.0许可协议进行翻译与使用

  • 回答 (2)
  • 关注 (0)
  • 查看 (401)

我正在研究一个Oracle数据库相当大的项目(尽管我的问题同样适用于其他数据库)。我们有一个Web界面,允许用户搜索几乎任何可能的字段组合。

为了使这些搜索更快,我们将索引添加到我们认为用户通常会搜索的字段和字段组合。但是,由于我们并不真正了解我们的客户如何使用此软件,因此很难确定要创建哪些索引。

空间不是问题; 我们有一个4TB的RAID驱动器,我们只使用它的一小部分。但是,我担心索引太多可能会导致性能下降。因为每次添加,删除或修改行时都需要更新这些索引,所以我认为在单个表上创建数十个索引是个不错的主意。

那么有多少指数被认为太多?10?25?50?或者我应该只覆盖真的,真正常见和明显的案例,而忽略其他一切?

提问于
用户回答回答于

这取决于表格上发生的操作。

如果有很多SELECT和很少的变化,索引所有你喜欢的。这些将(可能)加速SELECT语句。

如果这个表受到UPDATE,INSERTs + DELETE ,那么这些表会很慢,并且有很多索引,因为每次发生这些操作时都需要修改它们。

话虽如此,你可以清楚地添加很多毫无意义的索引到一个不会做任何事情的表中。将B-Tree索引添加到具有2个不同值的列中将毫无意义,因为它不会在查看数据方面添加任何内容。

用户回答回答于

我通常是这样做的。

  1. 在典型的一天中获取在数据上运行的真实查询日志。
  2. 添加索引使得最重要的查询在其执行计划中触及索引。
  3. 尽量避免索引具有大量更新或插入的字段
  4. 在几个索引后,获取一个新的日志并重复。

与所有的优化一样,当达到要求的性能时,我会停止(这显然意味着0点会得到特定的性能要求)。

扫码关注云+社区

领取腾讯云代金券

年度创作总结 领取年终奖励