SQL Server 索引性能 - 长列

Question

在 SQL Server (2005+) 中，我需要为 nvarchar(2000+) 的列(仅完全匹配)建立索引.解决这个问题的最可扩展、最高效的方法是什么？

在 SQL Server (2005+) 中，对具有以下类型的列进行索引的实际区别是什么:

nvarchar(2000)

char(40)

binary(16)

例如。将查找索引 binary(16)列比对索引的查找快得多 nvarchar(2000) ?如果有，多少钱？

显然，在某些方面，越小越好，但我对 SQL Server 如何优化其索引以了解它如何处理长度还不够熟悉。

Answer 1

当然二进制(16)会快得多 - 只需进行最快的计算:

SQL Server 页面始终为 8K

如果每个条目有 16 个字节，则可以在页面上存储 500 个条目

如果每个条目 (nvarchar) 有 4000 个字节，您最终将每页有 2 个条目(最坏的情况，如果您的 NVARCHAR(2000) 已完全填充)

如果您有一个包含 100'000 个条目的表，则必须有 200 页用于使用 binary(16) 键的索引，而使用 nvarchar(2000) 的同一索引则需要 50'000 页

即使只是添加 I/O 来读取和扫描所有这些页面也会扼杀您可能拥有的任何性能......

马克

更新:
对于我常用的索引，我尽量避免使用复合索引——从其他表中引用它们会变得相当困惑(WHERE 子句有几个相等比较)。

此外，定期检查和维护您的索引 - 如果您有超过 30% 的碎片，请重建 - 如果您有 5-30% 的碎片，请重新组织。在 http://sqlfool.com/2009/06/index-defrag-script-v30/ 查看一个自动的、经过良好测试的数据库索引维护脚本

对于 聚集键 在 SQL Server 表上，尽量避免 GUID，因为它们本质上是随机的，因此可能导致大量索引碎片，从而损害性能。此外，虽然不是硬性要求，但请尝试确保您的群集键是唯一的 - 如果不是，SQL Server 将向其添加一个四字节的唯一标识符。此外，聚集键被添加到每个非聚集索引中的每一个条目 - 所以在聚集键中，拥有一个小的、唯一的、稳定的(不变的)列(最好是不断增加的)是非常重要的，这给你最好的特性和性能 --> INT IDENTITY 是完美的)。