SQL Serverクエリが7 MB /秒を超えるディスクI / Oを使用しないのはなぜですか

IOmeterテストを使用して、200 MB /秒を超えるパフォーマンスを示すSSDを持っています。しかし、ローカルマシンからSQLクエリを実行すると、Windowsリソースモニターに7MB /秒を超えるディスクIOが表示されません。これは、実行に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がサービスを提供しているのと同じ速さで結果を消費していません。提案された方法のいずれかに従って、測定から行の消費を削除すると、最大IOスループットのtrue（r）の図が得られます。

• 実行後に結果を破棄する
• 結果をスカラー変数に割り当てる

まだ行っていない場合に備えてDBCC DROPCLEANBUFFERS、データがバッファーキャッシュではなくディスクから実際に読み取られるようにする必要があることは明らかです。「テスト時のみ、アクティブなライブ環境ではこれを行わない」などの通常の注意事項が適用されます。

他のいくつかのコメントに磨きをかける：

900万行を返すクエリを実行している間、CPU使用率は約13％にとどまり、9％はsqlserverに起因します...すべてのデータがRAMにある場合、3分よりも速く結果が返されませんか？

ここで正確に何をテストしていますか、その方法と理由は？900万行のクエリがa以外の場合、SELECT * FROM dbo.SomeTable生のIOスループットだけでなく、1001の要素が関係します。

お使いのインテルI7-3820は 4コアプロセッサです。テストクエリで並列プランが生成されない場合、システムのCPU使用率が20％を超えてスラッシュする可能性があるとは驚きます。

900万行を返すための3分は非常に疑わしいものであり、テストの全体像を把握していないことを示しています。私の推測では、これは最適ではない（並列ではない）クエリプランのケースであり、ネストされたループ演算子でいっぱいになり、何百万行もプルされますSELECT。

私は提案します：

1. SELECT *SQL Serverを介してIO のみをテストします。
2. クエリがIOを飽和させない理由を掘り下げたい場合は、クエリの実行プランに関する新しい質問。