如果我在 SQL Server 数据库上使用 nvarchar(n) 列作为聚集索引,与数字 (int) 索引相比,我是否会遭受显着的性能影响?此外,复合索引的性能如何比较?
5 回答
Sql 并不真正关心您的索引是否为数字,但根据列中的内容以及使用表的方式,您需要考虑一些事项。
通常,您希望使索引尽可能小,因此 nvarchar(4000)(最多 8000 个字节)确实很糟糕,但 varchar(3)(最多 3 个字节)会小于 int(4 个字节)。此外,您希望(在可能的情况下)将索引插入插入索引的末尾,这可以防止索引碎片化并导致性能问题。
如果您对表运行的查询仅包含索引中的列,则复合索引可以大大提高性能。这意味着当索引满足查询时,甚至永远不会触及实际的表。
有关索引的概述,请参阅Sql server index basics 。
如果您提供有关表格本身以及您希望如何使用它的更具体的详细信息,可能会更有帮助?
科林,
nvarchar 使用双倍的 varchar 列空间。如果 nvarchar 列是表上的唯一索引,那么命中可能不会那么多,但如果你在该表上也有非聚集索引,那么是的,你将受到性能影响。这是因为聚集索引也包含在非聚集索引的所有行中,并且您的非聚集索引将非常宽。另一方面,int 列仅占用 4 个字节,并且具有很大的范围来存储从 -2,147,483,648 到 2,147,483,647 的值,并且往往很窄。对于 4 个字节,nvarchar 列最多只能存储 varchar(2) 使用的空间,因为它使用的空间是 varchar 列的两倍。你知道你浪费了多少空间吗?
几乎可以肯定是的。
窄的、数字的和严格单调的是一个很好的聚集键。nvarchar 不是这些。
每个非聚集索引条目都引用聚集索引,因此您也会膨胀 NC 索引。
这是在整理/比较问题之前。
我认为这也取决于你的桌子的大小。对于较小的表,我怀疑您是否会注意到差异,但对于较大的表,例如 100 万行及以上,您可能会看到使用 nvarchar 的速度略有放缓。我想说它还取决于该字段实际包含的内容..即,它们是电子邮件等。
在谈论索引时,您必须将“性能”分为两个主题。
在插入、更新和删除时,索引会减慢您的数据库速度——集群索引比非集群索引更是如此,因为它可能必须在底层数据存储中移动数据。在这里,我同意 John 的观点,即顺序 int 将比 nvarchar 执行得更好。
但是,如果您无论如何都需要查询 nvarchar 字段,则该字段上的聚集索引将更能加快您的读取速度。
因此,您问题的答案实际上取决于您是否担心插入或读取的性能。