SQLインジェクションの引数はスキップします。これはあまりにもよく知られているため、パラメーターと非パラメーターのSQLの側面に焦点を当てます。
SQLバッチをサーバーに送信する場合、どのバッチでも、理解するには解析する必要があります。他のコンパイラと同様に、SQLコンパイラはAST を生成する必要があります。 テキストから、構文ツリーを操作します。最終的に、オプティマイザは構文ツリーを実行ツリーに変換し、最終的に実行プランを作成し、それが実際に実行されます。 1995年頃の暗黒時代に戻ると、バッチがアドホッククエリであるかストアドプロシージャであるかによって違いが生じましたが、今日ではまったく同じです。
ここで、パラメータが違いを生むのは、select * from table where primary_key = @pkのようなクエリを送信するクライアントです。 まったく同じSQLテキストを送信します 毎回、どのような価値に関心があるかに関係なく、次に何が起こるかというと、全体 上記のプロセスが短絡しています。 SQLは、メモリ内で未加工の未解析のテキストの実行プランを検索します。 （入力のハッシュダイジェストに基づいて）受信し、見つかった場合はその計画を実行します。つまり、解析も最適化も何も行われず、バッチはすぐに実行されます 。毎秒数百、数千の小さなリクエストを実行するOLTPシステムでは、この高速パスによってパフォーマンスに大きな違いが生じます。
select * from table where primary_key = 1の形式でクエリを送信する場合 次に、SQLは少なくともテキストを解析して、テキストの内容を理解する必要があります。これは、テキストが以前に表示されたバッチとは異なる新しいテキストである可能性が高いためです（1のような単一の文字でも） vs. 2 バッチ全体が異なります）。次に、結果の構文ツリーを操作し、単純なパラメーター化<と呼ばれるプロセスを試行します。 / a> 。クエリを自動パラメータ化できる場合、SQLは、以前に他のpk値で実行された他のクエリからキャッシュされた実行プランを見つけてそのプランを再利用する可能性が高いため、少なくともクエリを最適化する必要はなく、スキップします。実際の実行計画を生成するステップ。しかし、真のクライアントパラメータ化クエリで達成できる最短のパスである完全な短絡を達成したわけではありません。
SQL Server、SQL統計オブジェクト
を調べることができます。 サーバーのパフォーマンスカウンター。カウンターAuto-Param Attempts/sec 1秒間に何度も表示されますSQLは、パラメーターなしで受信したクエリを自動パラメーター化されたクエリに変換する必要があります。クライアントでクエリを適切にパラメータ化すると、各試行を回避できます。 Failed Auto-Params/secも多数ある場合 さらに悪いことに、クエリが最適化と実行プランの生成の全サイクルを実行していることを意味します。