优化查询以减少 i/o 压力是否有意义？答案

【问题标题】：Does it make sense to optimize queries for less i/o pressure?优化查询以减少 i/o 压力是否有意义？
【发布时间】：2011-04-28 06:22:00
【问题描述】：

我有一个只读数据库（产品），它依赖于自己的 Sql Server 2008。

我已经通过查看活动监视器 - 报告中最昂贵的查询来优化查询。我按 CPU 成本订购了报告。我现在有大约 50 次查询/秒，并且没有查询超过 300 毫秒。

CPU 时间正常 (30%)，内存仅使用了 20%（64GB）。

有一个问题：磁盘时间稳定在 100%（我查看了空闲时间性能计数器并使用了 ideras SQL 诊断管理器）。我可以看到产品数据库的行为与我的订单数据库不同，后者在不同的机器上并且具有更小的表：如果我查看分析器跟踪，我在产品数据库中的查询显示“读取”列中的值高于 50.000 .在我的订单数据库中，这些值从不高于 1000。product-db 中的查询使用大量通用表表达式，适用于大型表（有些大约 500 万个条目）。

我不确定是否应该花时间优化查询以提高 i/o 性能，或者是否应该只添加一个服务器。通过优化查询持续时间，我已经添加了缺失的索引。是否针对 i/o 进行了优化？

【问题讨论】：

这对于服务器故障来说可能是一个更好的问题。您是否只有一张包含事务日志、用户数据库文件和 tempdb 的光盘？如果不是，哪些磁盘队列长度较长？
@Martin Smith 他的数据库是只读的，所以我预计事务日志不会有很大的负载。
@Peter - 确实。不过，我有点不确定order db 的来源。 @Malcolm - 这是在完全独立的硬件上吗？
订单数据库位于完全不同的服务器上。我只是用它来查看没有 i/o 压力的系统上的跟踪是什么样的。

标签： performance sql-server-2008 hard-drive

【解决方案1】：

总会有下一个瓶颈。

他们说。

既然您已经调整了 CPU 使用率，那么 I/O 负载就会自然而然地占据主导地位。你的表现已经可以接受了吗？如果是，则停止，如果不是，您必须估计需要花费多少小时进行进一步调整，以及是否购买另一台服务器或更多硬盘可能更便宜。

再次关于 I/O 调整，尝试看看通过简单的措施可以实现什么。有时您可以用 CPU 换取 I/O，反之亦然。压缩就是一个例子。然后，您将调整您当前的瓶颈组件。

在您寻求使 I/O 更快之前，请尝试减少生成的 I/O。

【讨论】：

【解决方案2】：

为您的查询寻找明显的 IO 性能改进，但更重要的是，看看如何在服务器级别提高您的 IO 性能。

如果您的其他资源（CPU 和内存）没有过载，您可能不需要新服务器。考虑为日志和临时文件添加 SSD，和/或考虑是否可以经济实惠地将整个数据库安装到 SSD 阵列上。

当然，清除磁盘 IO 瓶颈可能会提高 CPU 使用率，但如果您的性能接近可接受，这可能会改善到您可以暂时停止优化的程度。

【讨论】：

【解决方案3】：

简而言之，是的。针对CPU 和 IO 进行优化。

具有高 CPU 的查询往往会执行不必要的内存排序、（有时效率低下）哈希连接或复杂的逻辑。

具有高 IO（页面读取）的查询往往会进行全表扫描或以其他低效方式工作。

10 次中有 9 次，相同的查询将在列表顶部附近，但如果您在高 CPU 上工作，但您仍然对性能不满意，那么请务必在高 IO procs 上工作下一个。

【讨论】：

【解决方案4】：

除非您使用 SSD 或数据库优化的 SAN，否则 IO 几乎总是数据库应用程序的限制。

所以是的，优化以尽可能摆脱它。

首先要做的是表索引。

然后，尽可能多地添加 RAM，直到数据库文件的完整大小。

然后对您的数据表进行分区（如果这样做是合理的），以便仅在一个或两个表分区上完成任何必要的表或索引扫描。

那么我想你要么购买更大的机器，甚至更多的 RAM 和/或购买 SSD 或 SAN 或带 SSD 的 SAN。

或者，您可以重建整个数据库应用程序以使用 NoSQL 或数据库分片之类的东西，并在中间接口层中实现所有关系、连接、约束等。

【讨论】：