nchar 与 nvarchar 性能

Question

您如何决定是使用nvarchar 还是nchar？

例如，我注意到由 sqlmembership 提供程序创建的默认成员数据库将电子邮件列声明为类型 nvarchar(256)

对我来说，这似乎是电子邮件列的一个不必要的大最大值。我怀疑在正常情况下，超过 40 或 50 个字符的电子邮件非常少见。

但由于电子邮件地址等数据的长度不同，是否应始终将它们存储为 nvarchar 以消除冗余空间？

如果使用 nvarchar 作为电子邮件列。在更改电子邮件地址的情况下，如果新电子邮件比以前的电子邮件长，这会导致许多页面拆分并因此产生很大的性能成本吗？

您是否考虑过将 nchar(40) 用于电子邮件地址并牺牲存储空间以换取不分页性能成本？

或者使用 nchar(40) 会显着增加数据库大小，从而导致查询速度受到其他性能影响？

“仅当您知道填充列的数据大小时才使用 nchar”是一个合理的规则吗？

Answer 1

超过 40 或 50 个字符的电子邮件非常罕见

毁掉你的模型只需要一个...

如果新邮件比之前的邮件长，会导致很多页面拆分

没有。但即便如此，这也不是您设计数据模型的方式。可以说，为了争论，每次更新电子邮件都会导致页面拆分。您会针对那个进行优化吗？不，因为预先分配一个大的固定大小（即使用 NCHAR(256)）要糟糕得多，它确实消除了更新时潜在的页面拆分（同样，如果这样的页面拆分会发生）但增加表大小的成本要低得多，这会转化为 IO 带宽和内存消耗，请参阅Disk space is cheap...THAT'S NOT THE POINT!!!。

为什么我说可变长度更新不会导致页面拆分？因为当行图像不再适合页面时，页面拆分是强制的。对可变长度列的更新可能会导致行溢出并使行保持与以前相同的大小，甚至更小。在某些情况下，行在溢出后会增加大小，但有几个条件可以实际触发页面拆分：

• 值更新必须触发行大小增加，仅当从小于Table and Index Organization 中描述的 24 字节指针的值更新为大于此指针大小的值时才会发生这种情况。
• 行大小的增加（根据定义，每个要更新的变量列最多增加 24 个字节，包括从 NULL 到非 NULL 的更新）必须导致行不适合页面。李>
• 将 other 字段推送到行外（即所有可变长度字段都已推送到行外）应该不可能回收行中的空间

我真的不相信你有如此奇怪和深奥的工作量，因为上述条件是推动你的设计的主要因素。使用方便长度的 NVARCHAR 来适应您将遇到的任何值。