我应该在事实表上创建聚簇索引吗？决不？总是？

Question

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

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

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

参考

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

Answer 1

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

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

Answer 2

我不想说总是而从不，但我认为在大多数情况下你会发现在事实表上使用聚簇索引是一件好事。建议不要在插入的列类型上创建聚簇索引，其值可以是随机的。例如，您不希望像GUID这样的聚簇索引。日期和顺序ID非常适合聚簇索引，尤其是范围查询。

你已经声明你知道聚集索引的优点，但就缺点而言，确实将取决于你如何使用它们来判断它们是否适合你。

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

2.）由于数据块是按索引的顺序排列的，因此更改密钥顺序的插入和更新可能会导致对数据块进行物理修改，以使它们与索引保持一致。按顺序插入键值可以缓解此问题。

Answer 3

拥有int (bigint)自动增量PK聚簇索引极大地简化了分区;而且，事实表越早或越晚达到这一点。所以，即使你认为你现在可能不需要它，也要创建一个。