sql-server - nchar 与 nvarchar 性能

Question

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

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

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

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

如果将 nvarchar 用于电子邮件列。如果更改电子邮件地址，如果新电子邮件比以前的电子邮件长，这是否会导致许多页面拆分并因此产生大量性能成本？

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

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

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

Answer 1

emails longer than 40 or 50 characters would be pretty rare

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

if the new email is longer than the previous email will this cause many page splits

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

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

• 值更新必须触发行大小增加，这只有在更新小于 Table and Index Organization 中描述的 24 字节指针的值时才会发生大于此指针大小的值。
• 行大小的增加(根据定义，每个正在更新的变量列最多增加 24 个字节，包括从 NULL 到非 NULL 的更新)必须导致页面不适合的行。<
• 将其他字段推到行外应该不可能回收行中的空间(即所有可变长度字段都已推到行外)

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