我本质上是一名开发人员——但时不时地，客户没有像样的 DBA 来处理这些问题，所以我被召唤来决定......
在处理合理大小的 SQL Server 数据库（比 Northwind 或 AdventureWorks 大；大约 2-4GB 的数据加上索引等）时，您的策略/最佳实践是什么 - 您是否使用多个文件/文件组？
如果有：有多少？为什么？
您决定何时摆脱“一个文件组处理所有内容”方法的标准是什么：
* database size?
* database complexity?
* availability / reliability requirements?
* what else?
如果您使用多个文件组，您使用多少个？一个用于数据，一个用于索引，一个用于日志？几个（多少）的数据？您选择的原因是什么 - 为什么使用确切数量的文件组:-)
感谢您的任何提示，指针，想法！
干杯，马克
基本的经验法则是将文件分隔到不同的卷以避免争用，但是您获得的性能提升量因 I/O 子系统和工作负载而异。例如，就性能而言，单个物理轴上的多个文件会很糟糕，但是卷位于具有数百个来自 RAID 10 阵列的驱动器的 SAN LUN 上的相同安排可能会很好。磁盘队列长度计数器是您的朋友，它是判断您是否遇到 I/O 瓶颈的最简单方法。
您正在查看数据库上的 I/O 模式——只读、多读、读写、多写、只写——并以此为基础。您还需要选择正确的 RAID 级别并确保正确设置了磁盘分区偏移量、RAID 条带大小和 NTFS 分配单元大小。有些人喜欢将非聚集索引分离到一个单独的文件组中，但正如我上面解释的那样，这里的性能提升各不相同。
除了性能，您还应该考虑可管理性和可恢复性。拥有一个用于 100GB 数据库的单一数据文件意味着您的恢复单元就是该文件。将其拆分为 4 个 25GB 文件组意味着您可以使用部分数据库可用性和零碎恢复，以便在单个文件组损坏时只需要恢复它。通过在多个文件组中对表和索引进行分区，您还可以限制数据库的哪些部分受到维护操作（例如索引碎片删除）的影响。
Tempdb 是一个特殊的案例，我将向您指出我的一篇博客文章，其中解释了为什么以及如何拆分 tempdb - 那里有很多误解。
在这里没有给你一个“全面概括”的建议，我会给你一堆白皮书和博客文章供你阅读：
白皮书：部分数据库可用性
博文：对 TF 1118 的误解（tempdb 布局）
希望这对你有帮助！
在分析表的当前大小和未来增长后，应做出将数据库拆分为不同文件组的决定。在我看来，除非你有一个大型数据库或数百万行的表，否则你应该仔细考虑利弊，因为你最终可能会产生比你修复的更多的性能问题。
在某些前提下，有些场景可能会很有趣：
您必须分析您的环境以确定文件组是否有助于满足您的 SQL Server 增长、使用和性能需求。
移动到多个文件组的一些关键指标（来自本文）：
如果您发现文件组可以提高数据库的性能，请在生产服务器上实施更改之前编写代码并在暂存环境中测试该过程。在实施更改之前准备一些测量值并在之前/之后进行比较。由于这些过程可能非常耗费资源和时间，因此请在维护期间执行这些过程。
不要忘记，在创建新对象（表和索引）时，请确保在正确的文件组中创建对象以确保预期的性能，并定期验证数据库对象是否在正确的文件组中并根据需要进行更正。