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