非数字索引的性能

Question

如果我在SQL Server数据库上使用nvarchar（n）列作为聚簇索引，那么与数字（int）索引相比，我会遭受显着的性能下降吗？另外复合指标的表现如何比较？

Answer 1

Sql并不在意你的索引是否是数字，但有些事情需要考虑，具体取决于列中的内容以及你如何使用表格。

一般来说，你要保持你的指标尽可能的小，从而为nvarchar（4000）（8000个高达字节）那真是糟透了。但一个varchar（3）（3个高达字节）会比INT（4个字节）的情况。你也想（在可能的情况下）将你的索引插入插入到索引的末尾，这样会导致索引分裂并导致性能问题。

如果您针对该表运行的查询仅包含索引中的列，则化合物索引可以大大提高性能。这意味着当索引满足查询时，实际表格甚至不会被触及。

有关索引的概述，请参阅Sql server index basics。

如果您提供关于表本身的更多具体细节以及如何使用它，可能会更有帮助？

Answer 2

几乎可以肯定是的。

狭窄，数字和严格单调是一个很好的聚集键。 nvarchar不是这些。

每个非聚集索引条目引用聚集索引，因此您也会膨胀NC索引。

这是整理/比较问题之前。

Answer 3

我认为这也取决于你的表的大小。对于较小的表格，我怀疑你会注意到一个区别，但对于较大的表格，说100万行甚至更多，你可能会看到nvarchar的轻微放缓。我会说这也依赖于什么领域实际contains..i.e，是他们的电子邮件等

Answer 4

科林，

为nvarchar使用VARCHAR列两倍的空间。如果nvarchar列是表上唯一的索引，那么命中可能不那么多，但如果在该表上还有非聚簇索引，那么是的，你将会有性能问题。这是因为聚簇索引也包含在非聚簇索引的所有行中，并且非聚簇索引将非常宽。另一方面，int列只占用4个字节，并具有很大的范围以存储从-2,147,483,648到2,147,483,647的值，并且往往是窄的。对于4个字节，nvarchar列最多只能存储varchar（2）使用的空间，因为它使用varchar列的空间的两倍。你看到你有多少空间浪费？

Answer 5

在谈论索引时，必须将“性能”分为两个主题。比非集群聚集索引更是这样，因为它可能要在底层数据存储迁移数据 -

在插入，更新和删除，该指数将减缓你的数据库了。在这里，我同意John的说法，顺序int将比nvarchar更好。

但是，如果你需要反正在为nvarchar现场查询，在该领域的聚簇索引将更加加快你的阅读。

所以你的问题的答案真的取决于你是否担心插入或读取性能。