我是一名开发人员 – 但时不时的，一个客户没有一个像样的DBA来处理这些问题，所以我打电话来决定….
当处理合理大小的SQL Server数据库（比Northwind或AdventureWorks大的东西，大约2-4GB的数据加上索引等等）时，您的策略/最佳实践是什么？ – 您是否使用多个文件/文件组？
如果是这样：多less？ 为什么？
什么是你的标准来决定什么时候离开“一个文件组”的方法：
* database size? * database complexity? * availability / reliability requirements? * what else? 如果您使用多个文件组，则使用多less个？ 一个是数据，一个是索引，一个是日志？ 几个（多less）的数据？ 什么是你select的理由 – 为什么你使用确切数量的文件组:-)
感谢任何提示，指针，想法！
干杯，马克
基本的经验法则是将文件分离到不同的卷上以避免争用，然而，I / O子系统和工作负载所带来的性能增益的巨大变化是很大的。 例如，单个物理主轴上的多个文件在性能上会有所下降，但是与具有来自RAID 10arrays的数百个驱动器的SAN LUN上的卷相同的安排可能会很好。 磁盘队列长度计数器是您的朋友，可以告诉您是否有I / O瓶颈。
您正在查看数据库上的I / O模式 – 只读，主要读取，读写，主要写，只写 – 并基于此。 您还需要select正确的RAID级别，并确保您的磁盘分区偏移，RAID条带大小和NTFS分配单元大小设置正确。 有些人喜欢将非聚簇索引分隔成一个独立的文件组，但是这里的性能增益就像我上面所解释的那样。
除了性能，您还应该考虑可pipe理性和可恢复性。 为100GB数据库提供单一的单一数据文件意味着您的恢复单元就是该文件。 将其拆分成4个25GB的文件组意味着您可以使用部分数据库可用性和零碎恢复，只需要在发生损坏时恢复单个文件组。 通过对多个文件组中的表和索引进行分区，还可以限制维护操作影响数据库的哪些部分（例如，删除索引碎片）。
Tempdb是一个非常特殊的情况，我会在你的博客文章中指出你的理由，解释为什么以及如何分解tempdb – 这里有很多误解。
在这里没有给你一个“全面概括”的build议，我会指给你一些白皮书和博客post供你阅读：
白皮书： 部分数据库可用性
博客文章：对TF 1118 （tempdb布局）的误解
希望这可以帮助你！
在分析当前表的大小和未来增长之后，应当决定将数据库分成不同的文件组。 在我看来，除非拥有数百万行的大型数据库或表格，否则您应该仔细考虑优点和缺点，因为您最终可能会创build比您修复更多的性能问题。
在某些前提下，有些情景可能会很有趣：
您必须分析您的环境，以确定文件组是否将有助于您的SQL Server增长，使用情况和性能需求。
一些关键指标转移到多个文件组 （从这篇文章 ）：
如果您发现文件组可以提高数据库的性能，请在生产服务器上实施更改之前，在暂存环境中编写代码并testing该过程。 准备一些测量，然后再实施更改并在之前/之后进行比较。 由于这些过程可能是非常耗费资源和耗时的，因此在维护期间执行这些过程。
当创build新对象（表和索引）时，请确保在正确的文件组中创build对象以确保预期的性能，并定期validation数据库对象是否位于正确的文件组中，并根据需要进行更正。