我们有一个相当大的 MS SQL 2008R2 数据库，它驻留在 SSD 驱动器上。驱动器本身只有大约 110Gb 的空间，并且数据库文件是驱动器上唯一的文件。
数据库处于“简单”恢复模式，只有两个文件，.MDF 和.LDF。
磁盘现在几乎已满：MDF 目前的大小为 109Gb。但是，SSMS 告诉我有将近 18Gb 的“可用空间”（在“常规”属性页面中），如果我完成Shrink文件的操作，它还会告诉我有 18Gb 的可用空间。SSMS 还告诉我数据库大小约为 132Gb，这让我感到惊讶 - 这不适合驱动器！
从我所读到的，这shrink是一个非常糟糕的主意。但是，我开始看到复制错误 ( could not allocate space for object)。我们之前曾尝试缩小数据库，但在几个小时内，文件又恢复到原来的大小。
我们应该如何进行 - 鉴于显然有 18Gb 的可用空间，SQL 是否应该自动使用该可用空间？或者就这么简单：我们真的需要更多的磁盘空间？
这是对先前问题的跟进。我有一个 SQL Server 2008 R2 标准服务器，它包含一个数据库，除了一个大表之外，它本身几乎没有任何东西。
该表有 100 多万行（35 列），并且每天以大约 250,000 行的速度增长。我们需要所有数据都“在线”，并且大多数列需要以某种方式可搜索。桌上的绝大多数活动是阅读；除了INSERT白天编辑的新数据外，无需更改任何内容。
用户对表执行一系列查询，从简单的查找记录请求到根据一系列条件提取数万行。我们对运行的查询只有有限的控制，性能开始受到影响，即使有索引也是如此。
问题的很大一部分是磁盘 I/O，我们正在通过改造基于 SSD 的阵列来解决这个问题。由于所有数据库文件都将位于这个新阵列上，因此共识是拥有多个数据库文件不会有任何区别，但将表拆分为单独的表可能是可行的方法。
我现在想知道什么是最好的方法。我正在与自己辩论的两个想法：
将表拆分为“层”
INSERT每天被编辑 的数据然后我会在一夜之间将数据“洗牌”到层级（数据库只能在上午 8 点到晚上 10 点访问，所以我有一个隔夜窗口来处理数据）。
为数据范围创建表
INSERT放入 2013 年第 2 季度的表中，然后转到 2013 年第 3 季度、2014 年第 4 季度等...如果这可以提高性能，我可以使用文件组使旧表“只读”。
选项 1 对我来说是最容易实现的，但我不确定这是否是一个完全疯狂的想法。选项 2 需要更多的工作来实施和维护，但如果它是此类问题的“最佳实践”，那么我将采用这种方式。
我们将不胜感激地收到任何和所有建议或替代想法 - 我认为这些类型的问题最好在设计时解决。
我们有一个用于托管单个数据库的 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 阵列，就够了吗？或者将数据库分区为单独的逻辑驱动器上的单独文件是一个更好的主意，即使它们本质上是相同的磁盘？同样，在同一阵列中的逻辑驱动器之间拆分数据库和日志文件会有什么不同吗？