0

我使用 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))

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

4

4 回答 4

3

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

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

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

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

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

于 2009-07-13T18:22:52.683 回答
2

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

于 2009-07-13T18:27:57.200 回答
1

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

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

于 2009-07-13T18:49:17.547 回答
1

没有或负增益，

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

处理明智：

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

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

于 2009-07-13T19:24:25.867 回答