Gen*_*нин 2 performance index database-design sql-server
代码有什么问题。或者它的结果，说明聚集索引是邪恶的 [1]？
以及如何揭穿，即回归传统神话和最佳实践？
[1]
揭穿关于聚集索引的神话 - 第 3 部分（示例脚本）
http://blogs.sqlserver.org.au/blogs/greg_linwood/archive/2006/09/16/377.aspx
由 gbn 编辑，2012 年 1 月
死链接曾经有一个“证明”聚集索引不好的脚本。
类似的问题：https : //stackoverflow.com/questions/4034076/reasons-not-to-have-a-clustered-index-in-sql-server-2005
该脚本具有相当广泛的 varchar 聚集索引。在用随机数据填充它之后，它也需要重建索引：你会有大量的碎片。
一个好的聚集索引是狭窄的、数字的并且严格单调递增：这就是为什么人们使用代理键......
没有聚集索引的表被称为“堆”，因为它正是：一堆位于磁盘上的数据。无论您重建 NC 索引多少次，它都会保持这种状态。除了临时表（使用加载/截断使用模式）之外，没有理由不使用集群主键。
编辑：该链接并没有揭穿聚集索引的神话，而是展示了如何创建不合适的聚集索引以及为什么索引维护很重要。第 1 部分和第 2 部分提到了书签查找（现在是 SQL Server 2005+ 中的关键查找）：一个好的 NC 索引将被覆盖，因此它们不会发生。
为了学习索引，我推荐Simple Talk的很多文章。像这个
| 归档时间： |
|
| 查看次数： |
344 次 |
| 最近记录： |