SAP SQL Anywhere におけるヒントを使用したSQL リクエストのカスタマイズ

この記事のオリジナルは、 Glenn Paulley がsybase.com に 2009 年 6 月に掲載したものです。その中で、Glenn は SQL Anywhere におけるヒントの使用によるクエリセマンティクスのカスタマイズについて解説しています。

特定の状況においては、ヒントは非常に便利になりえますが、ほとんどの場合、SQL Anywhere のクエリのオプティマイゼーションとクエリの実行においては、クエリとDMLの性能の実行を実現するために全てのコンテキストを考慮して「正しいこと」をする、というとてつもない仕事を行っているということに留意することが重要です。

SQL クエリの正確なセマンティクスに影響を与えるために使用できるメカニズム、特に、特定の SQL 文の結果への同時トランザクションの影響を隔離する（あるいは晒す）ためのものはたくさんあります。このようなメカニズムの 1 つが、使用されるカーソルのタイプです。

例を挙げると、INSENSITIVE カーソルは、同時アップデートの影響からクエリを隔離し、同じトランザクションからであっても、その結果の最初の FETCH より前に、OPEN 時の SQL クエリの全結果セットを実体化します。

一方、SQL Anywhere の KEYSET-DRIVEN (または SCROLL・value-sensitive) カーソルは、それらのローがアプリケーションによってFETCHされたものであると記憶し、同じ結果のローが再FETCH され、同時アップデート（または削除）される場合には、アプリケーションに警告（エラー）を返します。

他のメカニズムとして、SQL 文で使用されている分離レベルがあります。

SERIALIZABLEより低い ANSI SQL 分離レベルには、明らかに同時実行性を改善する利点があります。

しかしながら、同時更新やそれら間の相互作用が理由で、クエリ実行中にエラーが発生するリスクがあります。

他のセマンティックの効果のうち、テーブルヒントの使用は、クエリあるいはテーブルベースでさえセマンティックの変更の指定が可能です。

もともと、私は SQL クエリのヒントの使用は好きではありません。なぜならば、「クエリオプティマイザーに最適なアクセスプランを選択させなければならない」という強い偏見があるからです。

しかしながら、多くの場合において、クエリまたはテーブルヒントは、特にロックの動作を細かく制御するのに、非常に便利です。

続きはこちら：SAP SQL Anywhere におけるヒントを使用したSQL リクエストのカスタマイズ

SAPのSAP SQL Anywhere製品ページはこちら