每当我创建一个表时,我想知道是否有任何性能差异我是否说nvarchar (100)或nvarchar (1000)假设实际字符串大小将小于100.那有吗？
Rei*_*ica 54
根据文件:
nvarchar [(n | max)]
可变长度的Unicode字符串数据.n定义字符串长度,可以是1到4,000之间的值.max表示最大存储大小为2 ^ 31-1个字节(2 GB).存储大小(以字节为单位)是输入数据的实际长度的两倍+ 2个字节.
因此,在计算存储大小时,只有输入数据的实际长度才有意义.
文档没有说明它为什么存在,但长度参数很有用,因为它强制执行简单的限制约束(例如,有人不能输入2 GB的文本作为"名称").
HLG*_*GEM 19
当您需要nvarchar(10)时,不应该使用nvarchar(1000)的原因是为了防止将错误数据输入数据库.除非你喜欢它,否则电话号码会说"如果你想要一个真实的答案,就叫那个胖胖的秘书而不是可爱的秘书".(不是那么随机的例子我曾经发现给我们的实际客户档案)用户会很快找到答案什么领域足够大,他们可以使用它们来存储笔记,其中随着时间的推移往往使得该领域的数据无用.
至于nvarchar(Max),除非你期望有超过4000个字符,否则完全使用它是一个坏主意.查找索引和varchar(max)以查看原因.
小智 7
至于大小与性能,请记住,SQL服务器将存储nvarchar/ 的数据的初始值,varchar以及nchar/ char空间的整个值.例如:nvarchar(1000)存储的数据test data最初将占用9*2字节的空间或18字节.nchar(1000)无论如何,a 将占用1000*2字节(2000字节).
然后它继续以愉快的方式在页面上添加下一组数据(这是8k),直到页面满足(或接近)表的填充因子集.然后开始一个新页面.现在让我们假设一个用户需要更新这些数据并在前一个字段中输入一些内容,让我们说800字符长.现在该值需要更新并且将显着增长,但现在页面已满,当该字段的数据必须增长时,页面需要拆分并为数据腾出空间(除非填充因子足够低以允许增长).
该页面拆分将聚合为索引碎片,导致搜索/搜索时间更慢,更新时间更长.因此,如果数据发生显着变化,则对性能的影响可能会有所不同.
通常情况下,答案是:"依赖".
是的，从性能的角度来看很重要。
查询优化器查看此元数据以计划查询。它根据提供的长度估计行大小，这可能会导致性能问题。例如，当您需要对varchar（10）的列进行排序时，它可能计划在RAM上运行排序操作，但是可能计划在辅助存储上运行对varchar（1000）的相同查询。
我尝试使用领域知识并估计所需的大小。此外，您可能需要留出一些空间以备将来维护。例如，如果您认为数据最多可包含50个字符，请使用varchar（70）而不是50个字符，以便它可以处理应用程序使用中不可预测的将来更改。
我从这篇博客文章中了解了这一点（我不是作者）：http : //aboutsqlserver.com/2010/08/18/what-is-the-optimal-size-for-variable-width-columns/
注意：不要盲目选择较小的长度。更改字段大小可能会成为维护的头疼问题。我记得当我为LastName字段选择较小的长度时，一些用户因此无法在系统中注册。我们必须更新一个正在使用的关键数据库（这需要时间来增加字段长度），并编译程序并重新部署。如果我选择了合适的字段大小，则可以避免所有这些麻烦。
您可能还想了解nvarchar（max）和nvarchar（n）之间的差异，因为n> 4000 for 4000使该字段基本上类似于nvarchar（max）。（始终使用nvarchar（MAX）有什么缺点吗？）