回答:
DBシステムの最も遅い部分はディスクドライブです。ディスクレベルでボトルネックを解消すると、パフォーマンスが向上します。データが検索され、インデックスが使用されると、インデックスが最初に検索され、次に対応するデータがフェッチされます。インデックスとデータの両方が同じディスク上にある場合、競合が発生しています。一方、データが別の（物理）ディスク上にある場合、IOが高速になり、パフォーマンスが向上します。注意すべき主な部分は、データまたはインデックスが個別の物理ディスクまたはLUN上にあることです。
ディスクがある場合、システムのパフォーマンスを向上させる必要がある場合は、このようなシナリオを使用します。あなたのperfmonカウンタのためには使用することができPhysical Disk – Avg. Disk sec/Read、Physical Disk – Avg. Disk sec/Write、Physical Disk – Disk Reads/sec、Physical Disk – Disk Writes/sec変更の前と後の比較を持っています。
異なるドライブ間で同時I / Oを分散するとパフォーマンスが向上することは確かに真実です-それは神話ではありません。神話では、2回実行するとパフォーマンスが再び向上するということです。
あなたの場合はSAME、その後、2つのパーティションにあなたの配列を分割し、別の上に1と表の索引を置くのは時間の無駄です。
インデックスをデータから個別のファイルグループに分離する=パフォーマンスの改善は非常に議論の余地があります。基礎となるハードウェアがサポートされている場合、パフォーマンスの向上は「可能性があります」が、それらを異なるファイルグループに分離してもパフォーマンスが向上しないという事実によってのみ発生します。また、このためにパフォーマンスの向上を測定することも簡単ではありません。
参照：http : //weblogs.sqlteam.com/dang/archive/2008/08/01/Are-you-a-DBA-Monkey.aspx
最初に質問する必要があります。なぜこれをする必要があるのですか？
上記のリストの＃5の必要性をサポートするためにこのタスクを検討しましたが、まだ対処していませんが、良い提案のようです。
この決定は簡単ではないため、何をしようとしているかを把握し、サポートするハードウェアがあることを確認する必要があります。十分にテストしてパフォーマンスが大幅に向上しない限り、このような変更を行わないでください。インデックスを個別のファイルグループに分離するだけでパフォーマンスを向上させることが期待されている場合、それは価値がありません。
このアイテムに関する私の個人的な経験をお伝えします。現在のディスクドライブが必要なスペースに対して十分に大きくない場合、非クラスター化インデックスは別のファイルグループに格納する必要があります :-)。あなたはそれについて笑うことができます..しかしそれは起こります。
そのため、データドライブに空き領域を残そうとするときの緊急修正は、空き領域のあるドライブの新しいファイルグループですべての非クラスター化インデックスをオンラインで再作成する素敵なスクリプトを作成することでした。新しいストレージを購入するのは簡単かつ迅速だと思うかもしれませんが、実際にはそうではありません。
パフォーマンスに関しては、移動後も普通のことは何も見られませんでした。しかし、それはすべてがまとめられている大きなSANストレージボックスです:-)。
一般に; データとインデックスを同様のパフォーマンスを持つ別々のディスクに分割すると、そのテーブルへの実質的な書き込み操作またはそのインデックスを使用する大規模な読み取り操作のパフォーマンスが向上します。複数の物理ディスクに分割されたパーティションテーブルなど、他のI / O操作と同様の方法論。
ただし、ストレージにも大きく依存します。例えば; 素敵なFushion ioDrive（または同様のもの）を備えたサーバーがあり、個別の回転ディスクも持っている場合。ioDriveにすべてを保持する方が、より有益な場合があります（スペースが限られている場合を除く）。考慮すべき他の事項もあります-RAID構成、ネットワークストレージ構成。
同様のハードウェアを備えたテストサーバー上で、または（セカンダリサーバーがオプションでない場合のみ）一時的なデータを使用して、ピーク時以外にベンチマーキングを行います。上記のSankarによるDBAとMonkeyのリンクは、考えてみてください。