SQL Serverクエリが7 MB /秒を超えるディスクI / Oを使用しないのはなぜですか
IOmeterテストを使用して、200 MB /秒を超えるパフォーマンスを示すSSDを持っています。ただし、ローカルマシンからSQLクエリを実行すると、WindowsリソースモニターにディスクIO 7MB /秒以上）が表示されません。これは、クエリの実行に2分以上かかる場合でも当てはまります。ボトルネックになる可能性のあるものSSDから7MB /秒しか使用していないということですか？
私は走っています：
- Windows Server 2012スタンダード
- SQL Server 2008 R2
- Intel i7 3820
- 32GBのRAM
- sandisk SSD
コメントチェーンから、ASYNC_NETWORK_IO待機が問題がネットワークに関連していることを意味すると解釈しているようです。それは（通常）そうではありません。
@MartinSmithが（2回）をほのめかしたように、その最も可能性の高い説明はSSMSまたは使用しているアプリケーションであり、SQL Serverがそれらを処理するのと同じ速さで結果を消費していません。推奨される方法のいずれかに従って、測定から行の消費を削除すると、最大のスループットのtrue（r）の画像が得られますIOスループット：
まだ行っていない場合に備えて、DBCC DROPCLEANBUFFERSを実行して、データがバッファキャッシュではなくディスクから実際に読み取られるようにする必要があることは明らかです。 「テスト時のみ、アクティブなライブ環境ではこれを行わない」などの通常の注意事項が適用されます。
他のいくつかのコメントに磨きをかける：
900万行を返すクエリを実行している間、CPU使用率は約13％にとどまり、9％はsqlserverに起因します...すべてのデータがRAMにある場合、3分よりも速く結果が返されませんか？
ここで正確に何をテストしていますか、その方法と理由は？ 900万行のクエリがSELECT * FROM dbo.SomeTable以外の場合は、生のIOスループット以外にも、1001の要因があります。
Intel I7-382 は4コアプロセッサです。テストクエリで並列プランが生成されない場合、システムのCPU使用率が20％を超えてスラッシュする可能性があるとは驚きます。
900万行を返す3分は非常に疑わしいものであり、テストの全体像を把握できていないことを示しています。私の推測では、これは次善の（非並列）クエリプランのケースであり、ネストされたループ演算子でいっぱいになり、数百万行をプルします。つまり、単一のテーブルSELECTだけではなくIO消費。
私は提案します：
SELECT *テストするjustIO SQL Server経由。- クエリがIOを飽和させない理由を掘り下げたい場合は、クエリの実行プランに関する新しい質問。