クエリ処理におけるワーク・テーブルの使用 (All-rows 最適化ゴールの使用)

ワーク・テーブルは、クエリの実行中に作成される一時的な結果セットを実体化したものです。ワーク・テーブルを使用した方が代替方式よりもコストが小さいと SQL Anywhere が判断すると、ワーク・テーブルが使用されます。通常、ワーク・テーブルを使用すると、最初のいくつかのローをフェッチする所要時間は長くなります。ただし、ワーク・テーブルを使用できれば、すべてのローを検索するコストは大幅に低下する場合があります。このような違いがあるため、SQL Anywhere は optimization_goal の設定に基づいてさまざまな方式を選択します。デフォルトは First-row です。optimization_goal が First-row に設定されている場合、SQL Anywhere はワーク・テーブルを使用しないようにします。All-rows に設定されている場合、クエリの合計実行コストが減少するなら、ワーク・テーブルが使用されます。

optimization_goal 設定の詳細については、optimization_goal オプション [データベース]を参照してください。

ワーク・テーブルが使用されるのは、次の場合です。

クエリに 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 より高速です。

オプティマイザは、各クエリを分析し、ワーク・テーブルを使用した場合に最適なパフォーマンスが得られるかどうかを判断します。こうした最適化を利用するのに、ユーザ側の操作は必要ありません。

注意

上述の INSERT、UPDATE、DELETE は 1 回かぎりの操作のため、通常、パフォーマンスは問題にはなりません。ただし、問題が発生した場合は、コマンドを書き直して、競合とワーク・テーブルが作成されるのを防げます。これは、常に可能とはかぎりません。