1

我的应用程序中有多个表，它们都非常宽和非常高。宽度有时来自 10-20 列，具有各种数据类型 varchar/nvarchar 以及 char/bigint/int/decimal。我的理解是SQL中默认的页面大小是8k，但是可以手动更改。此外，varchar/nvarchar 列不受此限制，它们经常（总是？）移动到一个单独的位置，这个过程称为 Row_Overflow。Evenso，MS 文档指出 Row-Overflowed 数据会降低性能。“查询和执行其他选择操作，例如对包含行溢出数据的大记录进行排序或连接会减慢处理时间，因为这些记录是同步处理而不是异步处理的”

他们建议将大列移动到可连接的元数据表中。“然后可以在异步 JOIN 操作中查询”。

我的问题是，是否值得扩大页面大小以容纳宽列，还有其他性能问题吗？如果我没有这样做，而是将表分区为 1 个或多个元数据表，并且这些表在 100MM 记录范围内变得“大”，那么加入分区表不会远远超过好处吗？此外，如果 SQL Server 在单核机器上（或在 SQL Azure 上），我的理解是并行性被禁用，那么考虑到连接不再是异步的，这是否也会消除移动表引入分区的好处？您还有其他推荐的策略吗？

编辑：根据下面的精彩评论和一些额外的阅读（我本来应该做的），您不能手动更改 SQL Server 页面大小。此外，相关的 SO 帖子：我们如何更改 SQL Server 的页面大小？. 来自@remus-rusanu 的其他很好的答案

4

3 回答 3

6

您无法更改页面大小。

必要时将 varchar(x) 和 (MAX) 移出行 - 也就是说，页面本身没有足够的空间。如果您有很多大值，将它们移动到其他表中然后将它们连接到基表中可能确实更有效 - 特别是如果您并不总是查询该数据。

没有同步和异步读取该行外数据的概念。当您执行查询时，它会同步运行。您可能有并行化，但这是完全不同的事情，在这种情况下不会受到影响。

编辑：为了给您更多实用的建议，您需要向我们展示您的架构和一些实际的数据特征。

于 2012-04-30T19:28:05.020 回答
3

我的理解是SQL中默认的页面大小是8k，但是可以手动更改

“大页面”设置是指内存分配，而不是更改数据库页面大小。请参阅SQL Server 和大页面说明。恐怕你的理解有点不对劲。

作为一般非特定建议，对于宽固定长度列，最佳策略是部署row-compression。对于nvarchar，Unicode 压缩有很大帮助。对于具体的建议，您需要衡量。您遇到的确切性能问题是什么？你是怎么测量的？您是否使用了诸如等待和队列之类的方法来识别瓶颈，并且您肯定行大小和行外存储是一个问题？在我看来，您使用了其他“方法” ...

于 2012-04-30T19:43:50.320 回答
1
  • 您无法更改默认的 8k 页面大小
  • varchar并且nvarchar被视为任何其他字段，除非是(max)这意味着它们将被存储一点点不同，因为它们可以扩展页面的大小，而您不能使用其他数据类型来做到这一点，也是因为这是不可能的

例如，如果您尝试执行此语句：

create table test_varchars(
  a varchar(8000),
  b varchar(8001),
  c nvarchar(4000),
  d nvarchar(4001)
)

a 列和 c 列很好，因为它们的长度最大为 8000 字节。

但是，在 b 列和 d 列上会出现以下错误：

给列“b”的大小 (8001) 超过了任何数据类型所允许的最大值 (8000)。
赋予参数“d”的大小 (4001) 超过了允许的最大值 (4000)。

因为它们都超过了 8000 字节的限制。（记住orn前面的意思是unicode，占用双倍空间）varcharchar

于 2012-04-30T19:55:30.140 回答