我们有一个用于托管单个数据库的 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 阵列，就够了吗？或者将数据库分区为单独的逻辑驱动器上的单独文件是一个更好的主意，即使它们本质上是相同的磁盘？同样，在同一阵列中的逻辑驱动器之间拆分数据库和日志文件会有什么不同吗？