まず、パフォーマンスを適切にプロファイリングしていることを確認します。たとえば、ADO.NETからクエリを2回実行し、2回目が1回目よりもはるかに高速かどうかを確認します。これにより、アプリがコンパイルされ、デバッグインフラストラクチャが立ち上がるのを待つオーバーヘッドがなくなります。
次に、ADO.NETとSSMSのデフォルト設定を確認します。たとえば、SSMSでSET ARITHABORT OFFを実行すると、ADO.NETを使用する場合と同じように実行速度が低下する場合があります。
私がかつて見つけたのは、SSMSでSET ARITHABORT OFFを使用すると、ストアドプロシージャが再コンパイルされたり、別の統計が使用されたりすることでした。そして突然、SSMSとADO.NETの両方がほぼ同じ実行時間を報告しました。
これを確認するには、各実行の実行計画、特にsyscacheobjectsテーブルを確認します。それらはおそらく異なるでしょう。
特定のストアドプロシージャで「sp_recompile」を実行すると、関連する実行プランがキャッシュから削除されます。これにより、SQL Serverは、プロシージャの次の実行時に、より適切なプランを作成する機会が得られます。
最後に、SSMSを使用してプロシージャキャッシュとメモリバッファ全体をクリーンアップする「軌道からの核兵器」アプローチを試すことができます。
DBCC DROPCLEANBUFFERS
DBCC FREEPROCCACHE
クエリをテストする前にこれを行うと、キャッシュされた実行プランと以前の結果キャッシュが使用されなくなります。