我已将此提交至 stack overflow（这里），但意识到它应该真的在 serverfault 上。因此，对于不正确和重复的帖子表示歉意：
好的，我刚刚参加了一个 SQL Server 课程，我们讨论了在本地 RAID 和本地磁盘上使用多个文件组和文件的使用场景，但我们没有涉及 SAN 场景，所以我的问题如下；
我目前有一个 250 GB 的数据库在 SQL Server 2005 上运行，其中一些表有大量写入，而其他表则相当静态。数据库和所有对象都位于一个文件组中，其中包含一个数据文件。日志文件也位于同一卷上。我的理解是，应该在不同的磁盘上使用单独的数据文件以减少磁盘争用，并且应该使用文件组对数据进行分区。但是，使用 SAN 显然不会像使用小型 RAID 设置那样出现磁盘争用问题（或者至少我们目前没有），而且标准版不支持分区。
那么为了提高并行性我应该怎么做？
我对各种 Microsoft 出版物的理解是，如果我增加数据文件的数量，单独的线程可以分别对每个文件进行操作。这让我想到一个问题：我应该有多少个文件。每个核心一个？我是否应该将活动水平高的表和索引放在单独的文件组中，每个文件组的数据文件数量与核心数量相同？
谢谢
答案1
每个文件组应该有 X 个数据和日志文件，其中 X 是任务管理器可见核心的数量 - 这允许最佳 IO 行为。
这对于 tempdb 尤其重要 - 当分配/释放区（8 页组）时，文件有时会完全锁定在 SQL Server 中。Tempdb 覆盖大量对象。
为多个磁盘分配数据只对更好的 IO 有意义。好的 SAN 可能会使驱动程序的未完成 IO 能力饱和（队列长度通常最大为每张磁盘 256 个），因此好的 SAN 可能需要多个磁盘来保持足够的未完成 IO 以充分利用它。
但是即使没有良好的 SAN，多个文件也可以避免在进行插入等操作时出现单个文件访问的瓶颈。
超过上述 X 是没有意义的 - 因为每个核心最多只能在给定时间内运行一个线程。分配是原子的，因此每个核心在执行此操作时不会切换线程。但 X 个核心可能都希望同时扩展 ;)
同样重要的是：正确格式化磁盘。确保（2008 年之前的服务器）分区对齐，确保使用 64kb 节点大小格式化磁盘 - 否则您可能会浪费高达 40% 的 IO 性能。
分区根本不进入这个游戏；）
答案2
您应该仔细权衡是否使用多个文件以避免分配争用（即不将它们分布在多个主轴上）。尤其是对于临时数据库最佳实践最初发布后，引擎的工作方式发生了一些变化，并且对问题的整体理解也有了更好的改善。
简而言之，你应该做一些测试，看看是否真的存在这样的争用问题。你可以在这篇文章（和相关链接）中阅读更多内容：