我有一个巨大的数据库,其中只有 select 语句。并且有不同的应用程序使用它。在 15 根色谱柱中,有 12 根用于这些应用。是否建议在 Index 中使用所有这 12 列?如果否,问题是什么?
请注意,插入或更新每周只会发生一次或两次。这个想法是删除所有这些索引并在表加载后重新创建。
谢谢你的帮助。
我有一个巨大的数据库,其中只有 select 语句。并且有不同的应用程序使用它。在 15 根色谱柱中,有 12 根用于这些应用。是否建议在 Index 中使用所有这 12 列?如果否,问题是什么?
请注意,插入或更新每周只会发生一次或两次。这个想法是删除所有这些索引并在表加载后重新创建。
谢谢你的帮助。
@JustinHui 提供了一些很好的见解,并且由于您的情况是只读的,如果您有空间,您绝对可以为所有列建立索引。
但在你这样做之前,先用一小部分但相当大的数据进行测试。从 WHERE、JOIN、GROUP BY 和 ORDER BY 中比其他列更经常引用的列开始,看看您发现了哪些改进。如果需要,继续逐渐增加。我猜某些索引是矫枉过正的,但只有测试才能证明这一点。
最后,如果您想索引所有内容并且空间是一个问题,您可以随时使用Apache Solr查看数据库外部。一旦掌握了窍门,您就可以为所有内容编制索引,甚至为用户提供酷炫的多面搜索。而且您只需要每周重建一到两次 Solr 索引。
希望有帮助。
这取决于这些列的用途:
由于 SQL 引擎必须更新索引,索引列会使用更多磁盘空间、内存并降低 INSERT 和 UPDATE 速度。
当您检索数据并且索引字段用于 WHERE、JOIN、GROUP BY 或 ORDER BY 时,索引可以大大提高您的速度。
如果表很大,那么 12 个索引列可能会使用大量磁盘空间和内存,并有效地减慢任何数据的检索速度。最好的办法是使用性能调整器来确定哪些索引会给您带来最大的收益。
但是,这实际上取决于您的应用程序。尽管索引的列比例如此之大是不寻常的,但它可能适用于您的情况。