主页 / dba / 问题 / 2626
Accepted
Michael Hedgpeth
Asked: 2011-05-11 05:08:00 +0800 CST

何时应将非聚集索引存储在单独的文件组中？

  • 772

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

何时将非聚集索引存储在单独的文件组和驱动器上是可取的？什么 perfmon/profiler 证据会导致我得出这个结论？硬件是否在决定中起作用（RAID/SAN 是否用于单个驱动器）？

sql-server index

5 个回答

  1. Best Answer

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

    如果您需要从系统中获得更好的性能，您将使用这种方案，前提是您有磁盘。对于您的性能计数器，您可以使用Physical Disk – Avg. Disk sec/Read, Physical Disk – Avg. Disk sec/Write, Physical Disk – Disk Reads/sec,Physical Disk – Disk Writes/sec来比较您的更改前后。

    • 10

  2. 确实，在不同驱动器之间分布同时 I/O 会提高性能——这不是神话。这是一个神话，做两次将再次提高性能。

    如果您SAME，那么将您的数组分成两个分区并将索引放在一个分区上，将表放在另一个分区上是浪费时间。

    • 5

  3. 将索引与数据分离到单独的文件组中 = 性能改进值得商榷。如果你有底层硬件来支持它，性能改进“可能”会发生，但仅仅因为将它们分离到不同的文件组并不会给你带来性能提升。因此，测量性能提升也不容易。

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

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

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

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

    请注意，这个决定并不容易做出，您需要弄清楚您正在尝试做什么并确保您有硬件支持。不要进行这样的更改，除非您已经过良好测试并且您看到性能有显着提升，否则您可能会放弃这个想法。如果您期望通过简单地将索引分离到单独的文件组来提高性能，那是不值得的。

    • 5

  4. 我会告诉你我对这个项目的个人经验。当当前磁盘驱动器不足以容纳所需空间时，非聚集索引应存储在单独的文件组中:-)。你可以嘲笑它..但它发生了。

    因此，当我们即将在数据驱动器上没有可用空间时，对我们的紧急修复是创建一个很好的脚本，以在具有可用空间的驱动器上的新文件组上在线重新创建所有非聚集索引。人们会认为购买新存储既简单又快捷。但事实并非如此。

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

    • 1

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

    但是，它也很大程度上依赖于存储。例如; 如果您的服务器带有漂亮的 Fushion ioDrive（或类似的东西）并且还有单独的旋转磁盘。将所有内容保留在 ioDrive 上可能更有益（除非空间有限）。还有其他需要考虑的事项 - RAID 配置、网络存储配置。

    在具有类似硬件的测试服务器上或（仅当不能选择辅助服务器时）在非高峰时间使用临时数据进行一些基准测试。上面 Sankar 的 DBA-Monkey 链接值得深思。

    • 1

相关问题