• [アーティクル]

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 回はステートメントを実行するためです。

パラメータ マーカーを使用する場合、ステートメントを準備するとより効果的です。たとえば、アプリケーションが AdventureWorks サンプル データベースから製品情報を取得するように頻繁に要求されると想定します。アプリケーションでこの処理を実行できる方法は 2 つあります。

最初の方法を使用すると、アプリケーションでは、次のように要求された製品ごとに個別のクエリを実行できます。

SELECT * FROM AdventureWorks.Production.Product
WHERE ProductID = 63;

2 番目の方法を使用すると、アプリケーションによって次の処理が行われます。

  1. 次のように、パラメータ マーカー (?) を含むステートメントを準備します。

    SELECT * FROM AdventureWorks.Production.Product
WHERE ProductID = ?;

  2. プログラム変数をパラメータ マーカーにバインドします。

  3. 製品情報が必要になるたびに、バインドした変数にキー値を入力し、ステートメントを実行します。

ステートメントを 4 回以上実行する場合は、2 番目の方法がより効率的です。

SQL Server での実行プランの再利用方法により、SQL Server では、直接実行に対する準備/実行のモデルのパフォーマンスの利点はあまりありません。SQL Server には、現在の SQL ステートメントと、同じ SQL ステートメントの実行用に以前生成された実行プランを照合する効率的なアルゴリズムがあります。アプリケーションにより、パラメータ マーカーを使用して SQL ステートメントが複数回実行される場合、SQL Server では 2 回目以降の実行に最初の実行で使用した実行プランが再利用されます。ただし、プロシージャ キャッシュのプランが古くなった場合は、実行プランは再利用されません。準備/実行のモデルには次の利点もあります。

  • 識別のためのハンドルによって実行プランを検索する方が、SQL ステートメントを既存の実行プランと照合するために使用するアルゴリズムよりも効率的です。

  • 実行プランの作成および再利用のタイミングをアプリケーションで制御できます。

  • 準備/実行のモデルは、以前のバージョンの SQL Server など、他のデータベースに移植できます。