我们的数据库目前只有一个 FileGroup，PRIMARY，其中包含大约 8GB 的数据（表行、索引、全文目录）。
什么时候适合将其拆分为辅助数据文件？我应该注意哪些标准？
AskOverflow.Dev
我们的数据库目前只有一个 FileGroup，PRIMARY，其中包含大约 8GB 的数据（表行、索引、全文目录）。
什么时候适合将其拆分为辅助数据文件？我应该注意哪些标准？
这个问题有两个部分：何时添加新的 FILEGROUP，以及何时在文件组中添加新的 FILE。先说理论：
马克关于性能的主要原因是正确的。
第二个原因是灾难恢复。使用 SQL Server 2005 及更高版本，您可以进行文件组恢复。当灾难发生时，您可以先只恢复主文件组，然后使数据库部分联机以进行查询。用户可以在您恢复其他文件组时运行查询。这对于具有大量可能不需要立即使用的历史数据的数据库，或者需要将数据加载到当前表中而不需要访问历史数据的数据仓库非常有用。
另一个原因是数据组的读/写配置文件。如果您有一些不断写入的数据，以及其他需要大量读取活动的数据，您可以构建不同类型的存储来满足这些需求。你可以把重写入的东西放在raid 10上，把偏读的东西放在便宜的raid 5上。
现在，让我们谈谈文件与文件组。在 SQL Server 中放置对象时，必须将它们放置在文件组级别。您可以在文件组中放置表或索引，但不能选择特定文件。所以到目前为止，我们讨论的所有内容都是关于何时添加文件组 - 但是何时添加文件？
如果您正在设计存储，并且您有 80 个硬盘驱动器，则可以通过以下几种方式将其分解：
不同的存储子系统具有不同的性能配置文件。我曾使用过一些在 12-16 驱动器阵列上表现最佳的 SAN，而任何比这更大的 SAN 都没有性能提升。另一个示例是具有多路径的 SAN：如果您有多个 HBA 将服务器连接到存储，并且如果您的多路径软件不是真正的主动/主动，那么您可能需要每条路径一个阵列来分配负载。四个路径，四个驱动器池将在这些类型的驱动器上获得更好的性能。
在这些情况下，您最终会得到四个不同的阵列、Windows 下的四个不同的驱动器（除非您使用挂载点，即使那样它也是不同的文件夹），并且您将需要 SQL Server 中的四个单独的文件。这些单独的文件可以在同一个文件组中。
主要原因是性能。当您的主文件组磁盘驱动器上的 IOPS 容量用完时，您需要扩展到第二个文件组以根据存储配置将 IOPS 拆分到多个磁盘/LUN 上。
编辑：布拉德威尔逊对 SSD 发表了很好的评论。如果您使用的是复合 SSD/SATA/FC 存储系统，您可能希望在不同类型的存储上拥有不同的文件组。然后，您可以将极端 IOPS 要求表放到 SSD 文件组中，而历史/统计表可能存储在廉价的 SATA 文件组中。
我还要指出这个问题也有可恢复性/数据可用性方面。通过使用多个文件组，并且不在主文件组上放置任何用户定义的对象，您可以更灵活地启用在线恢复。这允许在文件组级别进行零碎恢复。
在线恢复在 2005 年以后的 sql server 的 Enterprise 和 Developer 版本中可用
想到的另一个想法是将只读静态引用数据与事务数据分开。对于较大的数据库，这可以减少执行备份所需的时间和/或空间。