SSD上のSQL Serverデータベース-テーブルごとに個別のファイルを使用する利点はありますか？

約30のテーブルがあるデータベースを作成しています。各テーブルには数千万の行が含まれ、各テーブルには単一の重要な列とプライマリ/外部キー列が含まれ、重い場合でもクエリの効率を最大限に高めます。更新と挿入を行い、クラスター化インデックスを多用します。2つのテーブルには可変長のテキストデータが含まれ、そのうちの1つには何億もの行が含まれますが、残りのテーブルには数値データのみが含まれます。

使用可能なハードウェア（約64 GBのRAM、非常に高速なSSD、および16コア）からパフォーマンスの最後の一滴を絞り出したいので、各テーブルに独自のファイルを持たせることを考えていました。 2、3、4、5、またはそれ以上のテーブルに参加しています。各テーブルは常に個別のスレッドを使用して読み取られ、各ファイルの構造はテーブルの内容と密接に調整されます。 SQL Serverが特定のテーブルの内容に追加するため。

1つの注意点は、SQL Server 2008 R2 Web Editionにこだわっています。これは、自動水平分割を使用できないことを意味します。これにより、パフォーマンスの向上として除外されます。

テーブルごとに1つのファイルを使用すると、実際にパフォーマンスが最大化されますか、それとも冗長になるビルトインSQL Serverエンジンの特性を見落としていますか？

次に、テーブルごとに1つのファイルを使用するのが有利な場合create table、特定の論理ファイルではなくファイルグループにテーブルを割り当てるオプションしか提供されないのはなぜですか？そのため、シナリオ内のすべてのファイルに対して個別のファイルグループを作成する必要があります。これは、SQL Serverが、提案していることを実行することで得られる利点を想定していないことを示唆しています。

各テーブルに独自のファイルを持たせることを考えていたので、2、3、4、5、またはそれ以上のテーブルに参加している場合でも、各テーブルは常に別々のスレッドを使用して読み取られ、各ファイルの構造はテーブルの内容と密接に連携することで、断片化を最小限に抑え、SQL Serverが特定のテーブルの内容に追加するのを速くすることができます。

一体何について話しているのですか？どこから情報を入手したかはわかりませんが、そのソースは必ず破棄してください。ここで想定していることから実際に正しいものはありません。

SQL ServerのSSDパフォーマンスに関する適切な議論を読みたい場合は、いくつかのブログシリーズがあります。いつものように、Paul Randalの記事が一番読みやすいです：

• ベンチマーク：SSDの紹介（パート1b：オーバーロードされていないログファイル配列）
• ベンチマーク：SSDの紹介（パート1：過負荷のログファイル配列ではありません）
• ベンチマーク：SSDの紹介（パート2：順次挿入）
• ベンチマーク：SSDの紹介（パート3：待機統計の詳細を含むランダム挿入）
• ベンチマーク：SSD上の複数のデータファイル（および最新のFusion-ioドライバー）

ブレントは、トピックに関する素晴らしいプレゼンテーションも提供しています。SSD上のSQL：Hot and Crazy Loveなどがあります。

これらすべてのプレゼンテーションを見ていくと、SSDのパフォーマンスが重要になるので、すべて書き込みに焦点を合わせていることにすぐに気付くでしょう。投稿文言はほぼ完全に読み取りに関するもので、これは別のトピックです。読み取りが問題である場合は、SSDではなくRAMについて、そして適切なインデックス付けとクエリ戦略について話す必要があります。

私の最初の提案は、両方の構成に対して負荷テストを行わずに、パフォーマンスに関する仮定を行わないことです。

過去にそのような構成（紙上で意味のあるもの）を見たことからの私の推測は、各テーブルを別々のファイルに置いてもパフォーマンスに測定可能なプラスの影響はないということです...たとえ測定可能であったとしても。

最後に、SQL Serverからパフォーマンスのあらゆる低下を絞り出すことになると、次のグラフを参照します（私のMicrosoft提供）：

アプリケーションの観点から可能な潜在的な最適化は、ハードウェア/データベース構成レベルでの可能な最適化を簡単に小さくします。したがって、適切に注意を集中してください。

他の人が指摘したように、テーブルごとに1つのファイルから直接の利点はありません。この神話がどのように生まれたのかについて、Steve Jonesからの素晴らしい概要を以下に示します。http：//www.sqlservercentral.com/blogs/steve_jones/2009/10/13/sql-server-legend-data-files-and-threads/

また、2008 Web Editionでサポートされていると思われるパーティションビューを調査することもできます。パーティションビューに対するコーディングにはいくつかのコツがありますが、パーティションテーブルの多くの機能を比較的簡単に模倣できます。

テーブルごとに個別のファイルを作成しても、パフォーマンス上のメリットは得られないと思います。正しいインデックスを使用すると、データベースサーバーのパフォーマンス（ディスク読み取り）が向上する可能性があります。

SQL Server 2008 R2は圧縮をサポートしていますか？はいの場合は、オンにします。

私が間違っている場合は修正してください。