我一直在阅读，并得到的印象是，如果你使用RAID，那么在一个文件组中使用多个SQL Server文件将不会有任何进一步的改进，好处是纯粹的pipe理（如果你开始用尽空间或通缉将数据分成可pipe理的块进行备份/平衡大型服务器机房的数据）。
然而，作为一个相当聪明的软件人员，假设即使对于较小的数据库，SQL Server将在LOGICAL文件基础上执行增长和locking操作（对于写入）也是不可想象的，所以即使使用RAID，也似乎在一个文件组中有多个文件来平衡I / O是合理的，还是重build来自分布式文件组的数据的时间大于减lesslocking的好处？
我也意识到行为和好处可能会有不同的表/ indeces /日志。
有一个很好的网站，当RAID已经到位时，区分多个文件的好处吗？
我最近回答了类似“多个数据文件和多个文件组”
提炼一个简洁的答案也相当复杂和困难。 这有助于了解SQL Server如何访问数据：请参阅“SQL Server 2000 I / O基础” ，它仍然有效
读取性能受RAM控制。 你不应该去磁盘读取数据：如果你这样做，你没有足够的内存。 在64位之前的那些日子里，如果你有一个500 GB的数据库，你只能装64GB的内存，那么你可以将索引拆分出来
编辑：你不经常需要在内存中的整个数据库，当你需要阅读它应该挂在caching直到被驱逐。
写性能由LDF卷pipe理。 看上面的文章提前login
如果卷发生故障，您可以将数据库文件拆分为可恢复性。 有了一个很好的备份/恢复计划，您可以单独使用MDF和LDF。
编辑：如果你的磁盘控制器失败了？ 你的磁盘全部来自同一供应商/批次/固件？ 如果2个磁盘在RAID 5中发生故障会怎么样？
如果在同一个卷上有多个文件，任何读取请求将比读取一个较大的文件花费更长的时间，通常是连续的。 这就是为什么文件服务器和数据库服务器通常build造不同
你不能find一个好的网站，因为它没有完成，正如你所指出的，每个人都倾向于对同一个文件组中的多个文件说“不”。
通过分区alignment方式获得更多收益， 并使用64k群集正确格式化NTFS a