其中一个问题是,所有主键都被创建为
NON CLUSTERED
索引而不是聚集索引。我知道每个表只能有一个聚集索引,你可能想将它放在非主键列上以提高查询性能等。但是,在这些表中没有其他
CLUSTERED
索引。所以我的问题是除了以上原因外,是否存在不在主键列上使用聚集索引的技术原因?
NON CLUSTERED
索引而不是聚集索引。CLUSTERED
索引。INT IDENTITY
最明显的选择)没有任何有效的理由。(在www.mssqltips.com上有一篇关于此主题的好文章)
堆表(没有聚集索引)
数据没有按任何特定顺序存储
除非也有非聚集索引,否则无法快速检索特定数据
数据页未连接,因此顺序访问需要参考索引分配映射(IAM)页
由于没有聚集索引,不需要额外时间来维护索引
由于没有聚集索引,不需要额外空间来存储聚集索引树
这些表在sys.indexes目录视图中具有index_id值为0
聚集表
数据按照聚集索引键排序存储
如果查询使用索引列,则可以根据聚集索引键快速检索数据
数据页链接以实现更快的顺序访问,但根据INSERTS、UPDATES和DELETES维护聚集索引需要额外时间
需要额外空间来存储聚集索引树
这些表在sys.indexes目录视图中具有index_id值为1
这里是另一个(在其他答案中已经提供了吗?)可能的原因(仍需理解):
我希望以后能更新,但现在更想将这些主题联系起来。
在一些仍在使用的B树服务器/编程语言中,固定或可变长度的平面ASCII文件用于存储数据。当向文件(表)添加新的数据记录/行时,记录会(1)附加到文件末尾(或替换已删除的记录),并且(2)索引会被平衡。以这种方式存储数据时,您不必担心系统性能(就B树服务器返回指向第一个数据记录的指针而言)。响应时间仅受索引文件中节点数量的影响。
当您开始使用SQL时,希望您意识到每次编写SQL语句时都必须考虑系统性能。在非索引列上使用“ORDER BY”语句可能会使系统崩溃。使用聚集索引可能会对CPU造成不必要的负载。现在是21世纪了,我希望我们在编写SQL时不必考虑系统性能,但我们仍然需要考虑。
在一些旧的编程语言中,检索排序数据时必须使用索引。我只希望今天仍然存在这个要求。我只能想象有多少公司由于对非索引数据编写的糟糕SQL语句而更新了其缓慢的计算机系统。
在我25年的编程经验中,我从未需要将我的物理数据按特定顺序存储,因此可能这就是为什么一些程序员避免使用聚集索引的原因。特别是如果您设计的系统将来可能会存储数百万条记录,很难知道权衡是什么(存储时间与检索时间之间的平衡)。