什么时候应该将非聚集索引存储在单独的文件组中？

我听说将索引存储在不同的文件组和驱动器上可以提高数据库的性能，因为驱动器不必在索引和索引所引用的数据之间来回移动。我也听说这是一个神话。

何时建议将非聚集索引存储在单独的文件组和驱动器上？什么性能/分析器证据会导致我得出该结论？硬件在决策中是否起作用（是否在单个驱动器上使用RAID / SAN）？

数据库系统中最慢的部分是磁盘驱动器。消除磁盘级别的瓶颈将提高性能。在查找数据并使用索引时，首先查找索引，然后获取相应的数据。如果索引和数据都在同一磁盘上，则说明正在发生某些争用。而如果数据位于不同的（物理）磁盘上，则IO发生的速度更快，从而提高了性能。需要注意的主要部分是数据或索引位于单独的物理磁盘或LUN上。

如果您需要从磁盘中获得更好的性能，则可以使用这种方案。为了您的性能计数器，您可以使用Physical Disk – Avg. Disk sec/Read，Physical Disk – Avg. Disk sec/Write，Physical Disk – Disk Reads/sec，Physical Disk – Disk Writes/sec之前和你的修改比较后有一个。

的确，在不同的驱动器之间同时分配I / O可以提高性能-这不是神话。神话是两次执行将再次提高性能。

如果您使用SAME，则将数组分成两个分区，将索引放在一个分区上，将表放在另一个分区上是浪费时间。

将数据中的索引分开到单独的文件组中=性能提高值得商bat。如果您有底层硬件来支持它，则性能可能会“提高”，但仅仅是将它们分离到不同的文件组并不能提高性能。因此，测量性能提升也不容易。

参考：http : //weblogs.sqlteam.com/dang/archive/2008/08/01/Are-you-a-DBA-Monkey.aspx

你应该先问这个问题。为什么需要这样做？

1. 您是否希望通过不包括索引来提高备份性能？
2. 您是否要提高对这些索引的读写性能？
3. 您是否这样做是为了更好地管理基础对象的放置？
4. 您是否拥有对性能有不同需求的大量数据？
5. 您是否要使用SSD的非聚集索引来提高性能等...

我查看了此任务以支持上述列表中对＃5的需求，尽管我们尚未对此采取行动，但对我来说似乎是一个不错的建议。

请注意，此决定并非那么容易做出，您需要弄清楚您要做什么，并确保您有支持的硬件。除非您进行了很好的测试，并且在性能方面有了显着提高，否则请勿进行此类更改。否则，您最好放弃这个想法。如果仅通过将索引分隔到单独的文件组中来期望提高性能，那是不值得的。

我会告诉你我对这个物品的亲身经历。当当前磁盘驱动器的空间不足以容纳所需空间时，非聚集索引应存储在单独的文件组中：-)。您可以为它笑..但是它发生了。

因此，当我们要在数据驱动器上保持无可用空间时，我们的紧急解决方案是创建一个不错的脚本，以在具有可用空间的驱动器上的新文件组上在线重新创建所有非聚集索引。有人会认为，购买新存储非常简单快捷。但是，事实并非如此。

关于性能，我们在搬家后没有发现任何异常。但这是一个大的SAN存储盒，所有东西都放在一起:-)。

一般来说; 将数据和索引拆分到单独的类似执行的磁盘上，可以提高对该表的大量写入操作或利用该索引的大型读取操作的性能。与某些其他I / O操作类似的方法，例如跨多个物理磁盘的分区表。

但是，它在很大程度上也取决于存储。例如; 如果您的服务器配备了不错的Fushion ioDrive（或类似的产品），并且还具有单独的旋转磁盘。将所有内容保留在ioDrive上可能更为有益（除非空间有限）。还需要考虑其他事项-RAID配置，网络存储配置。

在具有类似硬件的测试服务器上或在非高峰时段使用临时数据在（仅当没有辅助服务器的情况下）在测试服务器上进行一些基准测试。上面Sankar的DBA-Monkey链接令人深思。