SQL Server 2005-行大小对查询性能的影响?

如果RDBMS正在对行执行全表扫描,那么调整行的大小只是一个主要问题;如果查询只能使用索引选择行,那么行的大小就不那么重要了(除非返回的行非常多,而返回实际结果的IO非常重要)。

如果因为谓词不使用索引而对大量行执行全表扫描或部分扫描,那么行大小可能是一个主要因素。我记得有一个例子,在一个100000000行的表上,将较大的“data”列与用于查询的列拆分为不同的表,从而在某些查询上获得了数量级的性能改进。

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

我现在不知道你还想怎样提高表现了,这对我来说像是在抓救命稻草。这并不意味着这不是一个有效的方法。从我的经验来看,这个好处是巨大的。只是它通常比其他类型的优化要小。

不过,你要找的是统计学。收集它们有几种方法。很好的介绍 ->here .

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

所以对你的问题唯一有效的答案是:这取决于:)

提供更多信息,比如你已经做了什么样的优化,查询计划是什么样的,等等。

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

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

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

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

如果您对读取数据时最小化IO感兴趣,则需要检查索引是否覆盖查询。若要最小化IO,应选择包含在索引中的列或包含查询中使用的所有列的索引,这样优化器将从索引中读取数据,而不会从实际表行中读取数据。
如果您正在研究此类详细信息,可能应该考虑升级HW、更改控制器或添加更多磁盘以使查询处理器有更多可用的磁盘轴,从而允许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。高效的控制器和驱动程序使用更少的时间,为用户应用程序留下更多的处理时间,并提高总体吞吐量。

我要做的第一件事是确保您的索引已经重建;如果您正在处理大量的数据,并且索引重建是不可能的(如果SQL server 2005以后的版本可以在不锁定所有人的情况下执行联机重建),那么请确保您的统计数据是最新的(稍后将详细介绍)。

如果数据库包含有代表性的数据,则可以通过执行以下操作对查询使用的读取数(逻辑和物理)执行简单的测量:

SET STATISTICS IO ON
GO


-- Execute your query here


SET STATISTICS IO OFF
GO

在安装良好的数据库服务器上,应该很少或没有物理读取(高物理读取通常表示服务器需要更多RAM)。你在做多少逻辑阅读?如果这个数字很高,那么您需要考虑创建索引。下一步是运行查询并打开估计的执行计划,然后重新运行(首先清除缓存)以显示实际的执行计划。如果这些不同,那么你的统计数据就过时了。

我认为,在查看表的物理结构之前,首先要使用标准优化技术——检查执行计划、探查器跟踪等,看看是否需要调整索引、创建统计数据等——做得更远。