添加集群键的缺点

mlh*_*Dev 5 sql-server clustered-index nonclustered-index

我有一个数据库,它有多个表,没有任何聚集索引。我发现的所有内容都很小(< 500 行)。具体来说,PRIMARY KEY NONCLUSTERED根本没有其他索引。

在非常高的层次上,我理解没有聚集索引的性能限制。也许更多,所以我明白这不是最佳实践,但在我积极开始将非聚集主键转换为聚集主键之前,在转换这些索引时有什么注意事项吗?

我能想到的唯一一个是更新大表上的索引所需的时间,但同样这些时间相对较小。也许文件和分区,但我只有一个分区。

作为参考,这是一个运行在 SQL Server 2016 上的兼容 2008 的 SQL Server 数据库。这是在我们的主要 OLTP 系统中(这些表不涉及仓储和 ETL)。

RDF*_*ozz 1

回到过去(据我所知),理论上很小的表根本不需要索引。然而,聚集索引还有一些其他优点。

  • 更好的空间管理 - 没有聚集索引的表基本上不会释放磁盘空间,即使删除了行。
  • 所需空间更少 - 由于聚集索引内置于表的结构中,因此用聚集索引替换非聚集索引通常可以释放非聚集索引占用的大部分空间。

当然,对于 500 个行表,这两件事都应该太少而无法真正注意到。

不利的一面是,您的非聚集索引可能成为某些查询的覆盖索引,因此不需要触及实际表即可获取结果。因此,某些查询实际上可能会更慢。

当然,对于 500 个行表,这应该太少而无法真正注意到。

然而,我同意 BradC 的评论 - 如果表确实开始变得比预期大得多,我宁愿在上面有一个聚集索引。而且,如果您强制执行在每个表上放置聚集索引的标准,那么您不太可能得到一个包含 400MB 数据和 300MB 未使用空间的堆......