4

非常に簡単な背景：CLRストアドプロシージャを使用して、Active Directoryを使用してクエリ結果にアクセス制御を適用し、エンドユーザーが表示できる内容を制限しています。簡単に言うと、これは、ユーザーが結果（この場合はドキュメント）にアクセスするための基準を満たさないデータテーブルから行を削除することによって行われます。

このフィルタリングは、結果を表示する前にクライアントで以前に実行されていました。SQL 2008とはるかに強力なサーバーは、このアクセスフィルタリングをクライアントから移動する動機です。

私が疑問に思っているのは、「インライン」T-SQLをコマンドオブジェクト（この場合は）に渡す代わりに、CLRストアドプロシージャから元の通常のT-SQLストアドプロシージャを呼び出すことでパフォーマンスが向上することです。ストアドプロシージャが作成された元のT-SQLだけですか？誰かがこれについて言及している場所はどこにも見つかりません（おそらく、CLR SPの例として非常に混乱するためです:-)）。T-SQLストアドプロシージャはすでに最適化およびコンパイルされているので、あなたはそうかもしれませんか？

誰かが私のためにこれを確認することができますか？

私が十分に明確になったことを願っています。どうもありがとう、

コルム。

4

1 に答える 1

0

SQL CLRストアドプロシージャが特定のクエリを適切に（適切にパラメータ化して）実行し、それをかなり頻繁に実行する場合、そのT-SQLクエリは、「最適な実行プランの決定」シーケンス全体で1回実行され、プランキャッシュに格納されます。 SQL Serverの（そして、同様のT-SQLストアドプロシージャよりも速くSQL Serverから追い出されることはありません）。

そのため、元のT-SQLストアドプロシージャと同じように「プリコンパイル」されます。その観点からは、何のメリットもありません。

SQL CLRプロシージャ内からSQLステートメントを微調整して、最終的に破棄する結果セットにそれらの行が実際に含まれないようにすることができれば、SQL-CLRストアドプロシージャは適切にパラメータ化されたT-SQLクエリは、標準のT-SQLストアドプロシージャが返すデータが多すぎるため、一部の行を再度除外するよりも少し速い場合があります。

于 2011-12-17T20:29:12.830 に答える