ワークテーブルは、クエリの実行中に作成される一時的な結果セットを実体化したものです。ワークテーブルは、代替方式よりもコストが低い場合に使用します。通常、ワークテーブルを使用すると、最初のいくつかのローをフェッチする所要時間は長くなります。ただし、ワークテーブルを使用できれば、すべてのローを検索するコストは大幅に低下する場合があります。このような違いがあるため、SQL Anywhere は optimization_goal の設定に基づいてさまざまな方式を選択します。デフォルトは First-row です。optimization_goal が First-row に設定されている場合、SQL Anywhere はワークテーブルを使用しないようにします。All-rows に設定されている場合、クエリの合計実行コストが減少するなら、ワークテーブルが使用されます。
ワークテーブルが使用されるのは、次の場合です。
クエリに ORDER BY 句、GROUP BY 句、または DISTINCT 句があり、SQL Anywhere がローのソートにインデックスを使用しないとき。適切なインデックスが存在し、optimization_goal が First-row に設定されている場合、SQL Anywhere はワークテーブルを使用しません。ただし、optimization_goal が All-rows に設定されている場合は、ワークテーブルを作成してローをソートするよりも、インデックスを使用してクエリのローをすべてフェッチする方が高コストになることがあります。最適化ゴールが All-rows に設定されている場合、SQL Anywhere は負荷がより低い方式を選択します。GROUP BY と DISTINCT の場合、ハッシュベースのアルゴリズムではワークテーブルが使用されますが、通常はクエリからローをすべてフェッチする方が効率的です。
ハッシュジョインアルゴリズムが選択されたとき。この場合、ワークテーブルが中間結果の格納 (入力がメモリに収まらない場合) とジョイン結果の格納に使用されます。
sensitive 値を使用してカーソルが開かれたとき。この場合、ベーステーブルのロー識別子とプライマリキーを入れるワークテーブルが作成されます。このワークテーブルは、クエリから前方にローがフェッチされるたびに埋められます。ただし、カーソルから最後のローをフェッチすると、テーブル全体が埋められます。
insensitive セマンティックを使用してカーソルが開かれたとき。この場合、クエリが開かれるときに、ワークテーブルにクエリの結果が設定されます。
複数のローに UPDATE を実行し、UPDATE の WHERE 句または更新に使用するインデックスに、更新されるカラムが表示されるとき。
複数のローに対する UPDATE または DELETE が、修正されるテーブルを参照する WHERE 句にサブクエリを持つとき。
SELECT 文から INSERT を実行し、その SELECT 文が挿入テーブルを参照するとき。
複数のローに INSERT、UPDATE、または DELETE を実行し、その操作中に起動するように、対応するトリガーがテーブルに定義されているとき。
これらの場合は、操作の影響を受けるレコードがワークテーブルに入れられます。キーセット駆動型カーソルなど、場合によっては、ワークテーブルにテンポラリインデックスが作成されます。要求されたレコードをワークテーブルに抽出する操作は、クエリの結果が出るまでかなりの時間がかかります。上記の最初の例でソートを実行するのに使用できるインデックスを作成すると、最初のいくつかのローを検索する時間が短縮されます。ただし、ワークテーブルを使用すると、すべてのローをフェッチするための合計時間を短縮できる場合があります。これは、ハッシュとマージソートに基づくクエリアルゴリズムが許可されるためです。これらのアルゴリズムでは、シーケンシャル I/O が使用されます。これは、インデックススキャンと併用されるランダム I/O より高速です。
オプティマイザーは、各クエリを分析し、ワークテーブルを使用した場合に最適なパフォーマンスが得られるかどうかを判断します。こうした最適化を利用するのに、ユーザー側の操作は必要ありません。
注意 参照 |
DocCommentXchange で意見交換できます
|
Copyright © 2012, iAnywhere Solutions, Inc. - SQL Anywhere 12.0.1 |