sql-server - 我应该在事实表上创建聚集索引吗？绝不？总是？

Question

在数据仓库中，在事实表上创建聚集索引是否有缺点？（大多数时候，它将在日期时间列上）

你会回答“默认情况下......”是或否？

如果我不应该默认创建聚集索引，那为什么呢？（我知道聚集索引的优点，但有什么缺点？）

参考

http://blogs.sqlserver.org.au/blogs/greg_linwood/archive/2006/09/11/365.aspx

Answer 1

我总是建议在经常按给定值搜索的表（事务或仓库）上使用聚集索引。聚集索引（或任何索引）的缺点是您正在创建一个占用空间的额外数据存储。如果被索引的表很大……索引也会很大！除了数据库之外，您拥有的索引越多，您存储的数据就越多。但是，如果您需要搜索速度，那么您可能需要一个索引来帮助获得该速度。

但是，您也可以考虑在表的 ID 上创建聚集索引。然后在 Lucene（或 Lucene.NET）等产品中在数据库之外创建索引。然后，您可以搜索 Lucene 索引（在搜索方面具有更大的灵活性和功能），该索引将返回给定记录（或记录）的 ID，然后您可以使用它来识别数据库中所需的数据。这是我们在我目前的项目中使用了很多的路线，我必须承认它工作得非常顺利！创建索引要快得多（尤其是与在 SQL Server 中使用全文选项相比）。只是需要考虑的事情。

Answer 2

我讨厌说always和never，但我认为在大多数情况下，您会发现在事实表上使用聚集索引是件好事。不建议在插入的列类型上创建聚集索引，其中插入的值可以是随机的。例如，您不希望在 GUID 之类的东西上使用聚集索引。日期和顺序 ID 非常适合聚集索引，尤其是范围查询。

您已经说过您知道聚集索引的优点，但就缺点而言，实际上将取决于您如何使用它们以及它们是否对您不利。

1.) 每个表只能有一个聚集索引，因为它会更改数据块的布局以匹配索引的顺序。这就是聚集索引非常适合范围查询的原因

2.) 因为数据块是按索引的顺序排列的，所以改变键顺序的插入和更新会导致对数据块的物理修改，以使它们与索引保持一致。按顺序插入键值可以缓解这种情况。

Answer 3

拥有int (bigint)自增 PK 聚集索引极大地简化了分区；事实表迟早会达到这一点。因此，即使您认为现在可能不需要它，也请创建一个。