大きなテーブルとパフォーマンスの低下-次に何をすべきか？
単一のデータベースをホストするために使用されるWindows 2008 R2/SQL Server 2008 R2（標準）サーバーがあります。データベース自体は主に、ライブデータと履歴データの両方を含む単一の大きなテーブルで構成されています。テーブルは現在、35列の1億1,000万行であり、1日あたり約250,000行の割合で増加しています。レガシーコードが大量にあるため、残念ながらテーブルを小さなテーブルに分割することは実際には選択肢ではありません。
データベース自体（約100Gb）は、単一のSSDドライブ上の単一のファイルとして保持されます。サーバーには別の2つの10K SASブートOS、ページングなどに使用されるディスクがあり、サーバーには22GbのRAMがあります。
すべてが順調に進んでいますが、このテーブルのデータをクエリする必要がある数十人のユーザーがいます。これらのクエリの機能に対する制御は限られています。昨日から数百行を取得する場合もあれば、6か月前から数万行を取得する場合もあります。アクティビティの99.9％は行の読み取りです。 1日を通してライブデータがINSERTedされることを除けば、書き込みはほとんどありません。ピーク時には、大量のデータを返す単純なクエリが完了するまでに30分以上かかることがあります。
役立つインデックスがありますが、最終的なボトルネックはディスクI/Oのようです。設置されているSSDは最速ではないため、ハイエンドSSDドライブのRAID1 + 0アレイを改造してパフォーマンスを向上させることを検討しています（アレイカードがスループットを処理できることを確認しました）。
このアレイが配置されていると仮定すると、このデータベースへの読み取りスループットを向上させるための最良の計画は何ですか？超高速SSDアレイがある場合、それで十分ですか？あるいは、データベースが本質的に同じディスクを宛先としているとしても、データベースを別々の論理ドライブ上の別々のファイルに分割する方が良いでしょうか？同様に、同じアレイ内の論理ドライブ間でデータベースとログファイルを分割すると、何か違いがありますか？
Enterprise Editionを使用している場合は、パーティション分割をお勧めします。データはすべて同じコントローラーを経由して同じ基盤のディスクに書き込まれるため（そしてパーティション化を行わないと、比例的なフィルをあまり制御できず、多くのクエリでとにかくまだいくつかまたはすべてのファイルをヒットする必要があります）。
Enterprise Editionを使用していないので、1つの代替策は、データを複数のテーブルに分割し、それらを組み合わせるビューを持つことです。古いデータが更新されなくなったと想定すると、読み取り専用のファイルグループに配置することもできます。これにより、リソースの競合が緩和されます。必要に応じて、クエリロジックを複雑でうるさくすることができます。たとえば、最も簡単な解決策は、ビューに対してすべてのクエリを発行することですが、データアクセスレイヤーまたはストアドプロシージャロジックは、日付範囲パラメーターに基づいて、実行時にアクセスするテーブルを決定できます。特定のビューが独自のテーブルに存在するサブセットからでも非常に限定されたデータのサブセットをプルするように、フィルターされたインデックスを使用することもできます。これは必ずしも簡単なボタンではありませんが、何かを実装するためにエルボーグリースを使用することに興味があると思われる場合は、これらの詳細のいくつかについて詳しく説明できます。
もちろん、最も安価な修正は、問題にハードウェアを投入することです。具体的には、より多くのデータベースがメモリに収まるようにします。 RAMは安価であり、ボックスがそれをサポートしていると仮定すると、22 GBからのアップグレード（奇数ですか？） 128 64 GBは大いに役立ちます。 （OSが標準の場合も、32 GBで十分かもしれませんが、それほどではありません。）実際の実行計画と統計からI/Oメトリックを確認したいのですが、 SSD、データの大部分がメモリ内にある場合、それだけ高速になります。