将char数据存储为nvarchar有什么不利？ （而不是一贯的）

Question

我正在开发一个系统，我们有一些内部生成的参考代码。这些代码都可以使用简单的逐字符集来表示。此外，代码总是固定长度。

但是，在不同的数据库和表格中，代码存储为lib/和varchar的混合。我如何找到这种做法的不利成本？我可以在需要从nvarchar加入varchar或反之亦然时查看查询计划的实际变化，但不知道如何将其表示为业务成本。

我的问题有很多部分：

• 我如何收集一些具体的证据来证明我们当前设计的问题？
• 这些损害是否真的如此之大，以至于我应该首先关注它？
• 对固定长度数据使用可变长度字符字段是否会产生额外成本？
  • 如果是，该费用何时适用？只有当SQL写入磁盘时？在所有加入？等？

到目前为止我放在一起的最简单的例子显示了查询计划的不同，但当然，由于它太小，每个的查询成本可以忽略不计，整体运行时间不到一秒：

nvarchar

有关其他信息，我们在开发和测试中使用SQL Server 2014，在实时环境中使用2008。我不认为这个用例会有任何差异，但我想我是否也需要考虑这个问题呢？

Answer 1

nvarchar通常会使用两倍的空格varchar。

例外情况是，如果您正在使用页面或行压缩（在这种情况下会引入Unicode压缩）或双字节排序规则（在这种情况下，对于某些字符，varchar也可能每个字符占用两个字节）。

主要问题是nvarchar的数据类型优先级高于varchar，因此如果加入两个varchar方，则需要隐式强制转换为nvarchar或者至少阻碍了该方的索引使用。

（依赖于排序规则依赖于SQL Server是否仍可以管理dynamic seek尽管存在隐式转换，因此它可能不会完全排除嵌套循环连接的索引使用，但我怀疑您是否可以获得合并连接在没有中间排序的两种不同数据类型的两个索引上）

Answer 2

其中一个更明显的影响是不同的数据类型阻止使用外键约束。

从父表中删除一些基本行，同时保持所有子行不变，并将结果显示给老板。

你会得到答案＆＃39;没有人会做这么愚蠢的删除＆＃39;所以要做好准备。

Answer 3

隐式转换可能是最大的问题。有许多文章和博客文章讨论了隐式数据转换的负面性能影响。 如果代码总是固定长度且相当小（例如总是4个字符），那么Char或NChar将是更好的选择。 当表很大时，存储空间可能成为问题。 char（4）列在记录中占用恰好4个字节，而Varchar（4）需要4个字节加一对用于开销。 NChar或NVarchar基本上是空间要求的两倍。 这种代码通常是索引键的一部分，因此空间可以快速累加。它们也经常在条件子句（Where，Order By，Case等）中引用，因此隐式转换也可能成为主要的性能问题。 就个人而言，我会调查这些并尝试迁移到Char数据类型和根或父表以及代码元素中的非常一致的引用。 你还应该看看其他类似的情况。例如，来自/来自Integer的Char / Varchar是一个非常常见的问题。