SQL nvarchar 性能答案

【问题标题】：SQL nvarchar PerformanceSQL nvarchar 性能
【发布时间】：2009-07-13 18:14:02
【问题描述】：

我使用 MS Sql（2008 或其他）将本地化字符串存储在单个数据表中。大多数字符串都很短，可以用 varchar(200) 表示，而大约 10% 的字符串更长，需要 varchar(5000) 之类的字符串。我的问题是，如果我把它分成两个这样的表，在检索较短的字符串时是否有性能优势：

CREATE TABLE ShortTextTable(ID bigint IDENTITY(1,1) NOT NULL, TextValue nvarchar(200))
CREATE TABLE LongTextTable(ID bigint IDENTITY(1,1) NOT NULL, TextValue nvarchar(4000))

对比：

CREATE TABLE TextTable(ID bigint IDENTITY(1,1) NOT NULL, TextValue nvarchar(4000))

这个数据很少更新，我只关心读取。

【问题讨论】：

标签： sql sql-server performance sql-server-2008 nvarchar

【解决方案1】：

这取决于。可能是过早的优化。

显然，使用较小的列，每页可以容纳更多行，但您的使用模式可能意味着您提出的水平分区效率不高，因为它从两个新表中获取内容。我认为我们需要查看读取使用模式以及表是如何连接的。

此外，它正在划分一个逻辑上是一个空间的空间，并且将不再作为一个空间进行管理（即在两个地方都添加一个索引等）

在我这样划分它之前，你真的必须看到一个瓶颈并描述建议的更改。

我不确定，但可能字面意思根据列的长度对表进行分区（使用 SQL Server 的分区表功能）。同样，需要分析这是否有帮助。

【讨论】：

关于过早优化的要点。出于这个原因，我将坚持使用单表设计。
另一个问题是，使用 2 个表，您将无法再轻松地创建单个外键约束。

【解决方案2】：

不，没有真正的收获。要查看由于字符串大小交错而导致的瓶颈，特别是 base don an int PK，这将是一个真正的极端。
另一方面，使用这种存储模式的混乱是非常清楚和存在的：您必须根据字符串的长度来决定您还没有检索要查看哪个表！您可能最终会通过反复试验（尝试一个表，然后是另一个）来查找，这比任何 table nvarchar 存储结构问题都要浪费。

【讨论】：

【解决方案3】：

在 SQL 2005 和我相信 2008 中，您不会创建 NVarChar(5000)，因为您超过了使用这种数据类型的页面大小，此时 NVarChar(Max) 将起作用。为 nVarChar 指定数字 N 时，您的上限为 4000。

我相信，在这一点上，将内联存储值读取到页面与读取页面以获取指向 LOB 页面的 16 字节指针并从那里读取数据之间会存在性能差异。

【讨论】：

我最喜欢这个答案，但它有点含糊。
虽然可以通过多种方式对其进行理论化，但应通过检测/测量多次测试的结果来检查证明。从 LOB 空间读取项目比直接在存储记录的页面上读取项目要慢。考虑到从何处读取数据的决定，这种好处是否值得？未知。
使用 nvarchar(max) 仅当行中的数据大小超过 8036 字节时才处理 LOB。对于任何小于此的数据，数据将存储为常规 nvarchar。如果最多存储 200 个字符，则 nvarchar(200) 和 nvarchar(4000) 之间使用的物理空间没有区别。

【解决方案4】：

没有或负增益，

存储方面：可变长度字符串存储为字符数 + 2 个字节的长度。所以：数据的长度是相同的，但你会有第二个表的索引和键开销。

处理方式：

决定将其添加到哪个表中
纠正错字意味着它在错误的表中（忽略前向 ptrs 等）
处理 2 个表的键唯一性（如果它们有共同的父表）

现在，更重要的是，我看到您提到本地化，但您需要 nvarchar 吗？另一个 SO 问题：varchar vs nvarchar performance

【讨论】：