我有一个只读数据库（产品），它依赖于自己的 Sql Server 2008。
我已经通过查看活动监视器 - 报告中最昂贵的查询来优化查询。我按 CPU 成本订购了报告。我现在每秒有 50 个查询，并且没有查询超过 300 毫秒。
CPU 时间还可以（30%），内存仅被 20%（64GB）使用。
有一个问题：磁盘时间稳定在 100%（我查看了空闲时间性能计数器并使用了 ideras SQL 诊断管理器）。我可以看到产品数据库的行为与我的订单数据库不同，后者在不同的机器上并且具有更小的表：如果我查看分析器跟踪，我在产品数据库中的查询显示“读取”列中的值高于 50.000 . 在我的订单数据库中，这些值永远不会高于 1000。product-db 中的查询使用大量通用表表达式，适用于大型表（有些大约有 500 万个条目）。
我不确定是否应该花时间优化查询以提高 i/o 性能，或者是否应该只添加一个服务器。通过优化查询持续时间，我已经添加了缺失的索引。是否针对 i/o 进行优化是通常会做的事情？
简而言之，是的。针对CPU 和 IO进行优化。
具有高 CPU 的查询往往会进行不必要的内存排序、（有时效率低下）散列连接或复杂的逻辑。
具有高 IO（页面读取）的查询往往会进行全表扫描或以其他低效方式工作。
10 次中有 9 次，相同的查询将在列表顶部附近，但如果您已经在高 CPU 上工作，但您仍然对性能不满意，那么接下来一定要在高 IO proc 上工作。
总会有下一个瓶颈。
他们说。
既然您已经调整了 CPU 使用率，那么 I/O 负载就会自然而然地占据主导地位。你的表现已经可以接受了吗？如果是，请停止，如果不是，您必须估计需要花费多少小时进行进一步调整，以及是否购买另一台服务器或更多硬盘可能更便宜。
再次关于 I/O 调整，试着看看你可以通过简单的措施实现什么。有时您可以用 CPU 换取 I/O，反之亦然。压缩就是一个例子。然后，您将调整作为您当前瓶颈的组件。
在您寻求使 I/O 更快之前，请尝试减少生成的 I/O。
为您的查询寻找明显的 IO 性能改进，但更重要的是，看看如何在服务器级别提高您的 IO 性能。
如果您的其他资源（CPU 和内存）没有过载，您可能不需要新服务器。考虑为日志和临时文件添加 SSD，和/或考虑是否可以负担得起将整个数据库安装到 SSD 阵列上。
当然，清除磁盘 IO 瓶颈可能会提高 CPU 使用率，但如果您的性能接近可接受，这可能会改善到您可以暂时停止优化的程度。
除非您使用 SSD 或数据库优化的 SAN，否则 IO 几乎总是数据库应用程序的限制。
所以是的，优化以尽可能地摆脱它。
表索引是首先要做的事情。
然后，尽可能多地添加 RAM，直到数据库文件的完整大小。
然后对数据表进行分区（如果这样做是合理的），以便仅在一个或两个表分区上完成任何必要的表或索引扫描。
然后我想您要么购买具有更多 RAM 的更大机器和/或购买 SSD 或 SAN 或带有 SSD 的 SAN。
或者，您可以重建整个数据库应用程序以使用 NoSQL 或数据库分片之类的东西，并在中间接口层中实现所有关系、连接、约束等。