クエリの説明プランをどのように解釈しますか?

https://stackoverflow.com/questions/79266

09-06-2019
|

質問

SQL ステートメントがどのように実行されているかを理解しようとする場合、Explain Plan を確認することが推奨される場合があります。説明計画を解釈する（意味を理解する）ために経るべきプロセスは何ですか?「ああ、これは見事に働いている」と何が際立っているはずですか？「ああ、いや、そうではない」

解決

フルテーブルスキャンは悪く、インデックスアクセスは良いというコメントを見るたびに身震いします。フルテーブルスキャン、インデックス範囲スキャン、高速フルインデックススキャン、ネストされたループ、マージジョイン、ハッシュジョインなど。これらは単なるアクセスメカニズムであり、有意義な結論に達するためには、アナリストが理解し、データベース構造およびクエリの目的に関する知識と組み合わせる必要があります。

フルスキャンは、単にデータセグメント (テーブルまたはテーブル (サブ) パーティション) のブロックの大部分を読み取る最も効率的な方法であり、多くの場合、パフォーマンスの問題を示す可能性がありますが、それはコンテキスト内でのみ発生します。それがクエリの目的を達成するための効率的なメカニズムであるかどうか。データウェアハウスおよび BI 担当者として言えば、パフォーマンスに関する私の最大の警告フラグは、インデックスベースのアクセス方法とネストされたループです。

したがって、Explain Plan を読み取る方法のメカニズムについては、Oracle のドキュメントが優れたガイドとなります。 http://download.oracle.com/docs/cd/B28359_01/server.111/b28274/ex_plan.htm#PFGRF009

パフォーマンスチューニングガイドもよく読んでください。

また、Google で「カーディナリティフィードバック」を検索してください。これは、Explain Plan を使用して、クエリのさまざまな段階でのカーディナリティの推定値と、実行中に発生した実際のカーディナリティを比較するテクニックです。このメソッドの作者はヴォルフガング・ブライトリングだと思います。

つまり、結論は次のとおりです。アクセスの仕組みを理解する。データベースを理解します。クエリの意図を理解します。経験則を避けてください。

他のヒント

このテーマはこのような質問で答えるには大きすぎます。時間をかけて読んだほうがいいよ Oracle のパフォーマンスチューニングガイド

以下の 2 つの例は、INDEX を使用した FULL スキャンと FAST スキャンを示しています。

コストとカーディナリティに集中するのが最善です。例を見ると、インデックスを使用するとクエリの実行コストが削減されます。

これはもう少し複雑です (そして私はそれを100%理解しているわけではありません) が、基本的にコストはCPUとIOコストの関数であり、カーディナリティはOracleが解析すると予想される行数です。この両方を減らすことは良いことです。

クエリのコストはクエリと Oracle オプティマイザーモデルの影響を受ける可能性があることを忘れないでください (例:コスト、選択など)、統計を実行する頻度。

例 1:

スキャン http://docs.google.com/a/shanghainetwork.org/File?id=dd8xj6nh_7fj3cr8dx_b

インデックスを使用した例 2:

インデックス http://docs.google.com/a/Fukuoka-now.com/File?id=dd8xj6nh_9fhsqvxcp_b

そして、すでに示唆したように、TABLE SCAN に注意してください。通常、これらは回避できます。

シーケンシャルスキャンなどを探すと多少は便利ですが、現実は数字にあります...ただし、数値が単なる推定値である場合は除きます。通常は何ですか遠いクエリを見るよりも便利です プラン 実物を見ている実行. 。Postgres では、これが EXPLAIN と EXPLAIN ANALYZE の違いです。EXPLAIN ANALYZE は実際にクエリを実行し、すべてのノードの実際のタイミング情報を取得します。これにより、何があるかがわかります実はプランナーの代わりに起こっていること 考える 起こります。多くの場合、シーケンシャルスキャンはまったく問題ではなく、クエリ内の他の何かが問題であることがわかります。

もう 1 つの鍵は、実際に費用のかかるステップが何であるかを特定することです。多くのグラフィカルツールでは、さまざまなサイズの矢印を使用して、計画のさまざまな部分にかかるコストを示します。その場合は、細い矢印が入ってきて太い矢印が出るステップを探してください。GUI を使用していない場合は、数値に注目して、数値が突然大きくなっている箇所を探す必要があります。少し練習すれば、問題のある領域を簡単に特定できるようになります。

このような問題の場合、最善の方法は次のとおりです。アスクトム. 。特に、その質問に対する彼の回答には、オンラインの Oracle ドキュメントへのリンクが含まれており、そこではその種のルールの多くが説明されています。

留意すべき点の 1 つは、計画の説明は実際には最良の推測であるということです。

sqlplus の使い方を学び、AUTOTRACE コマンドを試してみることをお勧めします。いくつかの具体的な数字があれば、通常はより適切な決定を下すことができます。

しかし、あなたはASKTOMをすべきです。彼はそれについてすべて知っています:)

Explain の出力には、各ステップにかかった時間が示されます。まず最初に、長い時間がかかった手順を見つけて、その意味を理解する必要があります。シーケンシャルスキャンのようなものは、より優れたインデックスが必要であることを示します。これは主に、特定のデータベースと経験の調査の問題です。

「ああ、それは違う」という言葉は、多くの場合、 テーブルスキャン. 。テーブルスキャンでは特別なインデックスは使用されず、メモリキャッシュ内のすべての有用なインデックスを削除できます。たとえば、postgreSQL では次のようになります。

Seq Scan on my_table  (cost=0.00..15558.92 rows=620092 width=78)

たとえば、インデックスを使用して行をクエリするよりも、テーブルスキャンの方が理想的な場合があります。ただし、これは、あなたが探していると思われる危険信号パターンの 1 つです。

基本的に、各操作を調べて、その操作がどのように機能するべきかについての知識を考慮すると、その操作が「意味がある」かどうかを確認します。

たとえば、2 つのテーブル A と B をそれぞれの列 C と D (A.C=B.D) で結合しており、計画ではテーブルに対するクラスター化インデックススキャン (SQL Server 用語 -- Oracle 用語かどうかはわかりません) が示されているとします。 A に続いて、テーブル B に対する一連のクラスター化インデックスのシークへのネストされたループ結合が行われた場合、問題があったと考えるかもしれません。そのシナリオでは、エンジンが (結合された列のインデックスに対して) ペアのインデックススキャンを実行し、その後にマージ結合を実行することが予想される場合があります。さらに調査すると、オプティマイザにその結合パターン、または実際には存在しないインデックスを選択させている不正な統計が判明する可能性があります。

計画の各サブセクションに費やされた時間の割合を確認し、エンジンが何を行っているかを考慮してください。たとえば、テーブルをスキャンしている場合は、スキャンしているフィールドにインデックスを付けることを検討してください。

私は主にインデックスまたはテーブルスキャンを探しています。これは通常、where ステートメントまたは join ステートメント内の重要な列のインデックスが欠落していることを示しています。

から http://www.sql-server-performance.com/tips/query_execution_plan_analysis_p1.aspx:

実行計画で以下のいずれかが表示されている場合は、警告サインを検討し、潜在的なパフォーマンスの問題について調査する必要があります。それらのそれぞれは、パフォーマンスの観点から理想的ではありません。
* Index or table scans: May indicate a need for better or  additional indexes.
* Bookmark Lookups: Consider changing the current clustered index,
  consider using a covering index, limit
  the number of columns in the SELECT
  statement.
* Filter: Remove any functions in the WHERE clause, don't include wiews
  in your Transact-SQL code, may need
  additional indexes.
* Sort: Does the data really need to be sorted? Can an index be used to
  avoid sorting? Can sorting be done at
  the client more efficiently? 
これらを回避することは常に可能ではありませんが、回避できるほど、クエリのパフォーマンスが高速になります。

経験則

(詳細についても読んでみてください:

悪い

複数の大きなテーブルのテーブルスキャン

良い

一意のインデックスを使用する
インデックスにはすべての必須フィールドが含まれています

最も一般的な勝利

私がこれまでに見たパフォーマンスの問題の約 90% では、多数 (4 つ以上) のテーブルを含むクエリを 2 つの小さなクエリと 1 つの一時テーブルに分割することが最も簡単です。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow