テクノロジーの開発、最新の「柔軟な」アプローチの導入、およびデータベースの分野での「継続的な統合」により、エンドユーザーからのリクエストへのより迅速な応答の必要性が高まっています。 モバイルデバイスの普及の現状では、ユーザーのネイティブアプリケーションまたはWEBアプリケーションとのデータ交換を高速化するために、データ処理システムに変更を加えることがほとんど常に必要です。
私たちは、新しい技術の絶え間ない出現と導入を目の当たりにしています。 これはすごい！ 同時に、既存の「古い」技術は、サポートするために多くの注意と時間を必要とします。 「海」のデータ、「海」のデータベース、より多くの分散システム。 チューニングと最適化のための時間が残ります。 変更、保守、および変更を行うためのウィンドウを削減すると、既存の機器でのシステムの運用の継続性を高めるタスクが複雑になります。
データベース最適化のチューニングの分野では、「正しい」ソリューションを選択することが難しい状況がしばしばあります。 このような場合、さまざまなツールを使用して状況を評価し、改善する方法を見つける必要があります。 このようなツールを習得すると、将来同様の状況が発生した場合に最適なソリューションを見つけやすくなります。
この考えを支持して、 bulldba.com / db-optimizerブログの興味深い記事の翻訳を引用します。
バージョン3.0以降のEmbarcaderoの新しいDB Optimizerリリースには、Explainプランをクエリプランでオーバーレイするというすばらしい新機能があります！
[翻訳者注：
Visual SQL Tuning Visual Optimization（VST）ダイアグラムは、SQLテキストをグラフィカルなSQLダイアグラムに変換し、統計情報を使用してインデックスと制約をテーブルとビューに表示し、直接および暗黙のデカルト積などのSQLステートメントで使用される結合操作を示しますそして多対多の関係。 ]
たとえば、次のクエリをご覧ください。
SELECT COUNT (*) FROM a, b, c WHERE b.val2 = 100 AND a.val1 = b.id AND b.val1 = c.id;
列b.idおよびc.idはインデックスを作成します。 DB Optimizerウィンドウでは、このクエリは次のようになります。
定義によると、この種の接続の赤い線は、関係が「多対多」タイプである可能性があると言います。
質問：「このリクエストの最適な実行計画は何ですか？」
この「クエリツリー」の最適な実行プランの1つは次のとおりです。
- 最も選択的なフィルターから始めます。
- 可能であれば、従属テーブルでJOINを実行します
- そうでない場合は、トップレベルのテーブルでJOINを実行します
この図にはフィルターが1つしかありません。 これは、表Bの緑のF記号で示されています。この表には、クエリに選択基準「b.val2 = 100」があります。
では、表Bから始めましょう。将来の実装計画はどこに行きますか？ 「部下」とは「主」とは誰ですか？ 決定方法.. Oracleは、クエリのプランニングで同じ問題に直面します。 オラクルが他の決定ではなくその決定を下した理由を理解する方法は？ DB Optimizerの新機能がここで役立ちます。
DB Optimizerには、現在の実行計画をVSTダイアグラムにオーバーレイする非常に優れた機能があります（とても気に入っています！）。
OracleはテーブルBから始まり、テーブルAに接続します。結果はテーブルCに接続されます。このプランは最適ですか？
既存のインデックスをそのままにして、いくつかの制約を追加します
alter table c add constraint c_pk_con unique (id); alter table b add constraint b_pk_con unique (id);
DB Optimizerでクエリを再度分析しましょう。
これに基づいて、誰がマスターで誰がスレーブであるかがわかります。これに基づいて、最適なクエリ実行プランを決定します。これは、フィルタリングBで始まり、C、Aの順に接続されます。Oracleが追加された整合性制約を処理する方法を見てみましょう。
おわかりのように、実行計画は制約の観点から変更されており、Oracleは実装計画を準最適から最適に移行しています。
この話の教訓は、確かに、データベースの整合性制約を定義する必要があるということです。DBMSクエリオプティマイザーに貢献するからです。しかし、ここで見せたい主なことは、VSTダイアグラムでのクエリ実行プランの課しです。より簡単です。 クエリプランを重ね合わせた隣接するVSTダイアグラムを使用すると、違いをすばやく簡単に確認できます。
この機能について詳しく説明する予定です。 これは本当に素晴らしいです。
ジョナサンルイスの記事www.simple-talk.com/sql/performance/designing-efficient-sql-a-visual-approachの別の例を次に示します。
その中で、ジョナサンは要求について議論します：
SELECT order_line_data FROM customers cus INNER JOIN orders ord ON ord.id_customer = cus.id INNER JOIN order_lines orl ON orl.id_order = ord.id INNER JOIN products prd1 ON prd1.id = orl.id_product INNER JOIN suppliers sup1 ON sup1.id = prd1.id_supplier WHERE cus.location = 'LONDON' AND ord.date_placed BETWEEN '04-JUN-10' AND '11-JUN-10' AND sup1.location = 'LEEDS' AND EXISTS (SELECT NULL FROM alternatives alt INNER JOIN products prd2 ON prd2.id = alt.id_product_sub INNER JOIN suppliers sup2 ON sup2.id = prd2.id_supplier WHERE alt.id_product = prd1.id AND sup2.location != 'LEEDS')
VSTダイアグラムでは次のようになります。
ここにはいくつかのフィルターがあるため、どれが最も選択的かを知る必要があります。そのため、統計グラフをオンにします（表の下の青い数字はフィルターの割合、表の上の緑は表の行数、関係線の数は数字を表しますこれら2つのテーブルの結合によって返される行）。
これで、最適化を行う最適な方法を決定できます。 Oracleはそれを使用しましたか？
オプティマイザーのエラーが表示されますか？
濃い緑色は、実行が開始される場所を示します。 ここでは、メインリクエストの本文とサブクエリの2つの場所にあります。 赤は、リクエストのエンドポイントを示します。
別の例（Karl Arao）：
ここでは、実行は4か所から始まります。 各開始からの結果セットが、テーブルを結合する後続の各結果にどのように接続されているかに注目してください。 最終は赤で示されます。
[翻訳終了]
現代の環境でのデータベースシステムの最適化には、多くの場合、高度な知識が必要ですが、以前のように、ほとんどの部分は芸術のままです。
ヒントとインデックスの有効なオプションをすべてテストして、最適なソリューションを見つけることはほとんど不可能だとしましょう。 Embarcadero DB Optimizerなどのスマートツールを使用する必要があります。これは、セットアッププロセスをガイドし、提供されているものから最適なオプションを選択するのに役立ちます。
与えられた例では、その高度な機能がクエリ最適化の方向をすばやく見つけるだけでなく、「通常の」Oracleオプティマイザーによって行われた決定の説明を取得し、将来のオプティマイザーのより正確な作業を保証する欠落している説明を見つけるのに役立つことが示されました。
VSTダイアグラムの操作の詳細については、Jonathan Lewisの記事へのリンクまたはEmbarcadero Webサイトを参照してください。