SQL ステートメントの準備
SQL Server のリレーショナル エンジンでは、SQL ステートメントを実行前に準備する方式が完全にサポートされるようになりました。アプリケーションによって SQL ステートメントを複数回実行する必要がある場合、データベース API を使用して次の処理を実行できます。
ステートメントを 1 回準備します。これにより、SQL ステートメントがコンパイルされて実行プランが作成されます。
ステートメントの実行が必要になるたびに、コンパイル済みの実行プランを実行します。これにより、2 回目以降は実行ごとに SQL ステートメントを再コンパイルする必要がなくなります。
ステートメントの準備と実行は、API の関数およびメソッドによって制御されます。これは Transact-SQL 言語の一部ではありません。SQL ステートメントを実行するための準備/実行のモデルは、SQL Server Native Client OLE DB プロバイダーと SQL Server Native Client ODBC ドライバーによってサポートされています。準備要求時に、プロバイダーまたはドライバーによって、準備要求と共にステートメントが SQL Server に送信されます。SQL Server により、実行プランがコンパイルされ、そのプランに対するハンドルがプロバイダーまたはドライバーに返されます。実行要求時に、プロバイダーまたはドライバーのいずれかによって、ハンドルに関連付けられたプランの実行要求がサーバーに送信されます。
SQL Server では、準備されたステートメントを使用して一時オブジェクトを作成することはできません。また、準備されたステートメントでは、一時テーブルなどの一時オブジェクトを作成するシステム ストアド プロシージャを参照できません。これらのプロシージャは、直接実行する必要があります。
準備/実行のモデルを過度に使用すると、パフォーマンスが低下することがあります。ステートメントを 1 回だけ実行する場合は、直接実行のためのネットワークからサーバーへのアクセスは 1 回だけで済みます。1 回だけ実行される SQL ステートメントを準備してから実行する場合は、もう 1 回余分にネットワークからサーバーにアクセスする必要があります。つまり、1 回はステートメントを準備するため、もう 1 回はステートメントを実行するためです。
パラメーター マーカーを使用する場合、ステートメントを準備するとより効果的です。たとえば、アプリケーションが AdventureWorks2008R2 サンプル データベースから時折、製品情報を取得するように要求されるとします。アプリケーションでこの処理を実行できる方法は 2 つあります。
最初の方法を使用すると、アプリケーションでは、次のように要求された製品ごとに個別のクエリを実行できます。
SELECT * FROM AdventureWorks2008R2.Production.Product
WHERE ProductID = 63;
2 番目の方法を使用すると、アプリケーションによって次の処理が行われます。
次のように、パラメーター マーカー (?) を含むステートメントを準備します。
SELECT * FROM AdventureWorks2008R2.Production.Product WHERE ProductID = ?;プログラム変数をパラメーター マーカーにバインドします。
製品情報が必要になるたびに、バインドした変数にキー値を入力し、ステートメントを実行します。
ステートメントを 4 回以上実行する場合は、2 番目の方法がより効率的です。
SQL Server での実行プランの再利用方法により、SQL Server では、直接実行に対する準備/実行のモデルのパフォーマンスの利点はあまりありません。SQL Server には、現在の SQL ステートメントと、同じ SQL ステートメントの実行用に以前生成された実行プランを照合する効率的なアルゴリズムがあります。アプリケーションにより、パラメーター マーカーを使用して SQL ステートメントが複数回実行される場合、SQL Server では 2 回目以降の実行に最初の実行で使用した実行プランが再利用されます。ただし、プロシージャ キャッシュのプランが古くなった場合は、実行プランは再利用されません。準備/実行のモデルには次の利点もあります。
識別のためのハンドルによって実行プランを検索する方が、SQL ステートメントを既存の実行プランと照合するために使用するアルゴリズムよりも効率的です。
実行プランの作成および再利用のタイミングをアプリケーションで制御できます。
準備/実行のモデルは、以前のバージョンの SQL Server など、他のデータベースに移植できます。