NOCOUNT
SQL サーバー クエリでオフにすることの利点と欠点は何ですか?
7 に答える
SQL BOL から:
SET NOCOUNT ON は、ストアド プロシージャ内のステートメントごとに DONE_IN_PROC メッセージがクライアントに送信されるのを防ぎます。実際のデータをあまり返さないいくつかのステートメントを含むストアド プロシージャの場合、SET NOCOUNT を ON に設定すると、ネットワーク トラフィックが大幅に削減されるため、パフォーマンスが大幅に向上します。
詳細については、 http://msdn.microsoft.com/en-us/library/ms189837.aspxを参照してください。
また、SQLServerCentral に関するこの記事は、この件に関して優れています:
NOCOUNT のパフォーマンスへの影響
また、削減されるのはネットワーク トラフィックだけではありません。影響を受けた行数を把握するための余分なクエリが削減されるため、実行計画を最適化できるため、SQL Server の内部でブーストが発生します。
送信/表示に影響する行数を示すメッセージを停止するだけです。これにより、特にメッセージを返すステートメントが多数ある場合に、パフォーマンスが向上します。ネットワーク経由で (SQL サーバーとフロント エンドの間で) 送信されるデータが少なくなるため、パフォーマンスが向上します。
詳細は BOL: SET NOCOUNT
上記の理由で常に ON に設定していますが、proc に複数の結果セットがある場合、クライアント コードが台無しになる可能性があります。
SET NOCOUNT ONは1行のステートメントであり、SQLサーバーはクライアントにメッセージを送り返します。これはすべてのプロセス(つまり、選択、挿入、更新、削除)に対して実行されます。このメッセージを回避すると、データベースの全体的なパフォーマンスを向上させることができます。ネットワークトラフィックを削減する
EXの場合:
@a table(id int)を宣言します
nocountを設定します
@a select 1 unionselect2を挿入します
nocountをオフに設定します
個人的には、手動で実行され、多くのステートメントを使用してデバッグ メッセージを出力するクエリに対してNOCOUNTをオンにするのが好きです。Print
このようにすると、出力は次のようにはなりません。
ユーザー名の更新 (287行更新) 終わり パスワードの更新 (287行更新) 終わり 次のことをする (1127行更新) 終わり
そしてもっと好き
ユーザー名の更新 終わり パスワードの更新 終わり 次のことをする 終わり
更新する内容の機密性によっては、カウントを含めると役立つ場合があります。ただし、多くの出力を伴う複雑なスクリプトの場合は、通常は省略します。