SQL Server 2005 - Rowsize对查询性能的影响?

时间:2008-10-07 07:45:14

标签: sql-server performance

我试图通过搜索包含许多行的表来挤出一些额外的性能。 我目前的理由是,如果我可以从搜索到的表中丢弃一些很少使用的成员,从而减少了pagesplits的行数,因此当数据开始从内存溢出时,IO应该会丢失。

详细说明此类影响的任何好资源? 任何经历?

感谢。

7 个答案:

答案 0 :(得分:3)

如果RDBMS正在对行执行全表扫描,则调整行的大小只是一个主要问题,如果查询可以仅使用索引选择行,则行大小不太重要(除非您返回非常大的行数,其中返回实际结果的IO很重要)。

如果您正在进行全表扫描或对大量行进行部分扫描,因为您有不使用索引的谓词,那么rowsize可能是一个主要因素。我记得的一个例子是,在100,000,000行的表中,将大数据“数据”列拆分为用于查询的列的不同表,导致某些查询的性能提升了一个数量级。

我只希望在相对较少的情况下这是一个主要因素。

答案 1 :(得分:2)

我现在还没有你试图提高性能的其他方法,这似乎就像抓住我的稻草一样。这并不意味着它不是一种有效的方法。根据我的经验,收益可能很大。只是它通常与其他类型的优化相形见绌。

但是,您正在寻找的是iostatistics。有几种方法可以收集它们。可以找到一个非常好的介绍->here

答案 2 :(得分:1)

sql server查询计划优化器是一个非常复杂的算法,决定使用什么索引或什么类型的扫描取决于许多因素,如查询输出列,可用索引,可用统计信息,列中数据值的统计分布,行数和行大小。

因此,您问题的唯一有效答案是:它取决于:)

提供更多信息,例如您已经完成了哪种优化,查询计划是什么样的等等。

当然,当sql server决定执行表scna(聚簇索引扫描,如果可用)时,可以通过缩小行大小来降低io性能。但在这种情况下,您可以通过创建足够的索引(这是一个具有较小行大小的单独表格)来显着提高性能。

答案 3 :(得分:1)

如果应用程序是事务性的,那么请查看表中使用的索引。在这种情况下,表分区不太可能有很大帮助。

如果您有类似数据仓库的东西,并且正在对大量数据进行聚合查询,那么您可能会从分区获得一些里程。

如果要在两个不是1:M关系的大表之间进行连接,查询优化器可能必须分别解析每个表上的谓词,然后组合相对较大的中间结果集或运行像嵌套的慢运算符循环匹配连接的一侧。在这种情况下,您可以从触发器维护的非规范化表中获益,以进行搜索。我已经看到从几个大型应用程序的复杂屏幕的非规范化搜索表中获得了很好的结果。

答案 4 :(得分:1)

如果您对在读取数据时最小化IO感兴趣,则需要检查索引是否覆盖查询。要最小化IO,您应该选择索引中包含的列或覆盖查询中使用的所有列的索引,这样优化程序将从索引读取数据,并且永远不会从实际表行读取数据。
如果你正在研究这种细节,你应该考虑升级硬件,更换控制器或添加更多磁盘,以便为查询处理器提供更多的磁盘主轴,从而允许SQL同时读取更多数据。登记/> SQL Server磁盘I / O通常是大多数系统中瓶颈的原因。 I / O子系统包括磁盘,磁盘控制器卡和系统总线。如果磁盘I / O始终很高,请考虑:

将一些数据库文件移动到其他磁盘或服务器 使用速度更快的磁盘驱动器或廉价磁盘冗余阵列(RAID)设备 如果已使用其他磁盘,请将其添加到RAID阵列中 调整应用程序或数据库以减少磁盘访问操作。
考虑索引覆盖,更好的索引和/或规范化。

Microsoft SQL Server使用Microsoft Windows I / O调用来执行磁盘读取和写入。 SQL Server管理磁盘I / O的执行时间和方式,但Windows操作系统执行基础I / O操作。受I / O约束的应用程序和系统可能会使磁盘保持活动状态。

不同的磁盘控制器和驱动程序使用不同的CPU时间来执行磁盘I / O.高效的控制器和驱动程序使用更少的时间,为用户应用程序留出更多的处理时间,并提高整体吞吐量。

答案 5 :(得分:1)

我要做的第一件事是确保你的索引已经重建;如果您正在处理大量数据并且无法进行索引重建(如果SQL Server 2005以后您可以执行在线重建而不会将所有人都锁定),那么请确保您的统计信息是最新的(稍后会详细介绍)。 / p>

如果您的数据库包含代表性数据,那么您可以通过执行以下操作来执行查询正在使用的读取次数(逻辑和物理)的简单测量:

SET STATISTICS IO ON
GO


-- Execute your query here


SET STATISTICS IO OFF
GO

在井设置数据库服务器上,应该很少或没有物理读取(高物理读取通常表明您的服务器需要更多RAM)。你在做多少逻辑读物?如果此数字很高,那么您需要查看创建索引。下一步是运行查询并打开估计的执行计划,然后重新运行(首先清除缓存),显示实际的执行计划。如果这些不同,那么您的统计信息已过期。

答案 6 :(得分:0)

我认为您将首先使用标准优化技术 - 检查执行计划,分析器跟踪等,并查看是否需要调整索引,创建统计信息等 - 在查看之前你桌子的物理结构。