大表和糟糕的性能 - 下一步该怎么做？

Question

我们有一个用于托管单个数据库的 Windows 2008 R2 / SQL Server 2008 R2（标准）服务器。数据库本身主要由一个包含实时数据和历史数据的大表组成。该表目前有 1.01 亿行 35 列，并且以每天约 250,000 行的速度增长。不幸的是，由于大量遗留代码，将表拆分为较小的表并不是一个真正的选择。

数据库本身（大约 100Gb）作为单个文件保存在单个 SSD 驱动器上。服务器还有另外两个 10K SAS 磁盘用于引导操作系统、分页等，服务器有 22Gb 的 RAM。

尽管一切正常，但我们有几十个用户需要查询此表中的数据。我们对这些查询的作用的控制有限：有时它从昨天提取几百行，有时它是 6 个月前的数万行。99.9% 的活动是阅读行；除了INSERT全天正在编辑的实时数据之外，几乎没有写作。在高峰时段，返回大量数据的简单查询可能需要半小时或更长时间才能完成。

我们有一些有用的索引，但最终的瓶颈似乎是磁盘 I/O。现有的 SSD 并不是最快的，因此我们正在考虑改装高端 SSD 驱动器的 RAID1+0 阵列以提高性能（我们已经检查了阵列卡可以处理吞吐量）。

假设我们有这个数组，那么增加这个数据库的读取吞吐量的最佳计划是什么？如果我们有一个超快的 SSD 阵列，就够了吗？或者将数据库分区为单独的逻辑驱动器上的单独文件是一个更好的主意，即使它们本质上是相同的磁盘？同样，在同一阵列中的逻辑驱动器之间拆分数据库和日志文件会有什么不同吗？

Answer 1

如果您使用的是企业版，我建议您进行分区。单独的逻辑驱动器上的单独文件不太可能提供太多帮助，因为数据都通过同一个控制器并写入同一个底层磁盘（并且没有分区，您对比例填充没有太多控制，这意味着许多查询将无论如何，可能仍然需要点击几个或所有文件）。

由于您没有使用企业版，因此​​一种替代方法是将数据拆分为多个表，然后使用将它们组合在一起的视图。假设不再更新旧数据，您甚至可以将其放在只读文件组中，这将缓解一些资源争用。您可以根据需要使查询逻辑变得复杂和挑剔；例如，最简单的解决方案是只针对视图发出所有查询，但您的数据访问层或存储过程逻辑可以 - 基于日期范围参数 - 决定在运行时访问哪个表。您甚至可以使用过滤索引，这样某些视图甚至可以从其自己的表中存在的子集中提取非常有限的数据子集。这不是

当然，最便宜的解决方法是使用硬件解决问题：特别是，让更多的数据库适合内存。RAM 很便宜，假设你的盒子支持它，我会说从 22 GB（什么奇数？）升级到128 64 GB 会有很长的路要走。（如果操作系统也是标准的，即使 32 GB 也可能有帮助，但没有那么多。）虽然我很想看到一个实际的执行计划和统计 I/O 指标的查询，这个查询需要半小时才能从SSD，如果大部分数据在内存中，它会快得多。