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个条目
• 如果每个条目有4000个字节(nvarchar),那么每页最多会有2个条目(最坏的情况是,如果您的NVARCHAR(2000)已完全填充)

如果你有一个包含100'000个条目的表,你必须有200个页面用于二进制(16)键的索引,而你需要50'000个页面用于nvarchar(2000)相同的索引

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

渣

更新:
对于我常用的索引,我尽量避免复合索引 - 从其他表引用它们只是相当混乱(WHERE子句与几个相等比较).

此外,定期检查和维护您的索引 - 如果您有超过30%的碎片,重建 - 如果您有5-30%的碎片,重新组织.查看经过充分测试的自动DB索引维护脚本,网址为http://sqlfool.com/2009/06/index-defrag-script-v30/

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

Answer 2

你从错误的方向思考这个问题:

• 创建满足性能目标所需的索引
• 不要创建不需要的索引

无论一个列是一个列binary(16)还是nvarchar(2000)一点都没有区别,因为你不要只是不加考虑地添加索引.

不要让索引选择决定您的列类型.如果您需要索引nvarchar(2000) 考虑全文索引或为列和索引添加哈希值.

根据您的更新,我可能会使用HashBytes()函数和索引创建校验和列或计算列.请注意,校验和与加密哈希不同,因此您更有可能发生冲突,但您也可以匹配文本的全部内容,并且它将首先使用索引进行过滤.HashBytes()不太可能发生冲突,但它仍然可能,因此您仍需要比较实际列.对每个查询和每次更改计算哈希值,HashBytes也更昂贵.