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

Question

我试图从搜索具有许多行的表中挤取一些额外的性能。

我的当前想法是，如果我可以从被搜索的表中丢弃一些很少使用的成员，从而减小行大小，那么页面分裂的数量和因此产生的IO应该会下降，在数据开始从内存溢出时会带来好处。

有没有详细说明这种效果的好资源？

有什么经验吗？

谢谢。

- Torbjörn Gyllebring

Answer 1

调整行的大小只有在RDBMS对行执行全表扫描时才是一个主要问题，如果您的查询只能使用索引选择行，则行大小不那么重要（除非您返回了大量行，其中返回实际结果的IO很重要）。

如果您正在对大量行进行完整表扫描或部分扫描，因为您有谓词未使用索引，则行大小可能是一个重要因素。我记得有一个例子，在大约有1亿行的表中，将较大的“数据”列从用于查询的列中拆分到另一个表中，可以使某些查询的性能提高一个数量级。

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

- mmaibaum

---

我认为你可能低估了有多少数据库查询正在使用表扫描或非常宽的行的“书签查找”！我将尝试在我知道正在使用整个表行进行搜索的查询上进行测试。 - Kenny Evitt

Answer 2

我不知道你尝试了什么来增加性能，这对我来说似乎是无稽之谈。但这并不意味着它不是一个有效的方法。根据我的经验，好处是显著的。只是通常会被其他种类的优化所掩盖。

然而，您要寻找的是iostatistics。有几种方法可以收集它们。可以在这里找到一个相当不错的介绍。

- TToni

Answer 3

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

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

请提供更多信息，例如您已经执行了哪些优化，查询计划的样子等等。

当然，当SQL Server决定执行表扫描（如果有聚集索引），您可以通过缩小行大小来减少IO性能。但在这种情况下，通过创建适当的索引（实际上是一个具有较小行大小的单独表）可以大大提高性能。

- Jan

Answer 4

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

如果您有类似数据仓库的东西，并且正在对大量数据进行聚合查询，则可能会从分区中获得一些收益。

如果您正在对两个大型表执行联接操作，这些表不处于1：M关系中，则查询优化器可能必须单独解析每个表上的谓词，然后组合相对较大的中间结果集或运行像嵌套循环匹配联接一侧的慢操作。在这种情况下，您可以从由触发器维护的非规范化表中获得搜索的好处。我曾经在几个大型应用程序的复杂屏幕上看到了从非规范化搜索表中获得的良好结果。

- Nigel Campbell

Answer 5

如果您有兴趣在读取数据时最小化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。高效的控制器和驱动程序使用更少的时间，为用户应用程序留下更多的处理时间，并增加总体吞吐量。

- massimogentilini

Answer 6

我会首先确保您的索引已经重建；如果您正在处理大量数据且无法进行索引重建（如果使用SQL Server 2005或更高版本，则可以执行在线重建而不锁定所有人），则请确保您的统计信息是最新的（稍后会详细介绍）。

如果您的数据库包含代表性数据，则可以通过执行以下操作来对查询使用的读取数量（逻辑和物理）进行简单测量：

SET STATISTICS IO ON
GO


-- Execute your query here


SET STATISTICS IO OFF
GO

在一个设置良好的数据库服务器上，应该没有或很少有物理读取（高物理读取通常表明您的服务器需要更多 RAM）。你正在做多少逻辑读取？如果这个数字很高，那么您需要考虑创建索引。下一步是运行查询并打开预估执行计划，然后重新运行（首先清除缓存）以显示实际执行计划。如果这些不同，则您的统计信息已过时。

- Mitch Wheat

Answer 7

我认为在考虑表的物理结构之前，首先应该使用标准的优化技术 -- 检查执行计划、分析器跟踪等，看看是否需要调整索引、创建统计信息等。

- mwigdahl