此表的最快模式方法？答案

【问题标题】：Fastest Schema Approach for this Table?此表的最快模式方法？
【发布时间】：2011-12-13 20:15:28
【问题描述】：

我在 SQL Server 2008 数据库中有下表：

该表很少被修改，但经常使用 a 访问

SELECT Data 
WHERE ID = @X 
AND Scope = @Y

命令。

Data 可以是从空白到几页文本的任何内容。 ID+Scope 将永远是独一无二的。该表将包含几千个唯一 ID 和少于 20 个唯一 Scope 值。

我正在努力确保我对键/索引使用了最佳策略。目前，我刚刚使用ID 和Scope（按此顺序）获得了主要的非集群密钥集。

【问题讨论】：

为什么使用 uniqueidentifier，int 或 bigint 有巨大的空间。世界上只有少数几个数据库会拥有超出其限制的表。仅此一项就可以减少事情并因此加快速度。
在这种情况下，INT 绰绰有余。 Uniqueidentifier 用于“随机访问”下一个 id。 ID 最初是从多个位置创建的，并非所有位置都在数据库中。
这里不使用 GUID 的好文章...sql-server-performance.com/2005/guid-performance
+1 有帮助，但在我的情况下仍然认为这不是问题，因为表很少被修改，甚至在范围内选择唯一 ID 本身（例如 @X OP 是变量，而不是参数），因此没有传输开销。

【解决方案1】：

假设 ID 本身不是唯一的，并且您不倾向于将 ID 类型更改为 INT，那么您所做的几乎是最佳的。

我要添加的一件事是对您的主键进行聚类，以获得更好的性能。这比 N West 的添加聚集索引的解决方案更可取，因为这样您将有两个重复的索引（PK 和聚集索引），这会损害写入性能而不会提高读取性能。最好简单地聚集您已经拥有的索引：主键。

编辑添加：由于您的表很少更新，因此使用 GUID 键字段不应像在频繁更新的表上那样使您退缩。不理想，但在您的特定情况下，它的影响应该很小。

不过，在最初几次必须手动将某人在便利贴上潦草地写的 GUID 输入到查询窗口中之后，您可能会觉得很烦人。

【讨论】：

【解决方案2】：

CREATE UNIQUE CLUSTERED INDEX ON <TableName> (ID, Scope)

使用聚集索引将加快查询速度，因为您只需遍历树以获取每个 ID/范围。

请注意，使用 GUID 会很慢。但它会比堆或非集群扫描更快...

【讨论】：