是否更改SQL Server中的页面大小是处理"宽"表的最佳选择?

she*_*ven 1 sql sql-server query-optimization

我的应用程序中有一个非常宽且非常高的多个表.宽度有时是10-20列,包含各种数据类型varchar/nvarchar以及char/bigint/int/decimal.我的理解是SQL中的默认页面大小是8k,但可以手动更改.此外,varchar/nvarchar列除此限制外,它们通常(始终?)移动到一个单独的位置,即一个名为Row_Overflow的进程.Evenso,MS文档指出,行溢出数据会降低性能."查询和执行其他选择操作,例如对包含行溢出数据的大型记录进行排序或连接会减慢处理时间,因为这些记录是同步处理的,而不是异步处理的"

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

我的问题是,是否值得扩大页面大小以容纳宽列,是否还会出现其他性能问题?如果我没有这样做,而是将表分成一个或多个元数据表,并且表格在100MM记录范围内变得"大",那么加入分区表是否会远远超过好处?此外,如果SQL Server在单个核心机器上(或在SQL Azure上),我的理解是并行性被禁用,那么这也会消除移动表介绍分区的好处,因为连接将不再是异步的?您推荐的其他策略是什么?

编辑:根据下面的好评和一些额外的阅读(我本来应该做的),你不能手动改变SQL Server页面大小.另外,相关SO帖子:我们如何更改SQL Server的页面大小?.来自@ remus-rusanu的其他很棒的答案

Mar*_*sen 6

您无法更改页面大小.

必要时,varchar(x)和(MAX)会在行外移动 - 也就是说,页面本身没有足够的空间.如果你有很多大值,将它们移动到其他表然后将它们连接到基表上可能更有效 - 特别是如果你并不总是查询那些数据.

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

编辑:为了向您提供更实用的建议,您需要向我们展示您的架构和一些实际的数据特征.