90

SQL ステートメントがどのように実行されているかを理解しようとするときは、実行計画を確認することをお勧めします。EXPLAIN PLAN を解釈する (意味を成す) には、どのようなプロセスを経る必要がありますか? 「おお、これは見事に動いているな」と目立たせるべきは何か?対「いや、そうじゃない」

4

11 に答える 11

81

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

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

そのため、Explain Plan を読む方法のメカニズムについては、Oracle のドキュメントが適切なガイドです

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

また、「カーディナリティ フィードバック」の Google もあります。これは、説明プランを使用して、クエリのさまざまな段階でのカーディナリティの見積もりと、実行中に発生した実際のカーディナリティを比較できる手法です。Wolfgang Breitling がメソッドの作成者だと思います。

要するに、アクセスメカニズムを理解することです。データベースを理解する。クエリの意図を理解します。経験則は避けてください。

于 2008-10-01T12:31:22.673 に答える
13

この主題は、このような質問に答えるには大きすぎます。Oracleのパフォーマンスチューニングガイドを読むには、少し時間がかかるはずです。

于 2008-09-19T11:13:30.050 に答える
5

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

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

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

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

例 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 に注意してください。通常、これらは回避できます。

于 2008-09-17T03:41:26.110 に答える
4

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

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

于 2008-09-17T05:43:11.997 に答える
3

本当にこのような問題の場合、最善の方法はASKTOMです。特に、その質問に対する彼の回答には、オンラインの Oracle doc へのリンクが含まれており、そのような規則の多くが説明されています。

覚えておくべきことの 1 つは、Explain Plan は実際には最良の推測であるということです。

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

しかし、ASKTOM する必要があります。彼はそれについてすべて知っています:)

于 2008-09-19T01:16:37.393 に答える
2

1 つの「ああ、それは違います」は、多くの場合、テーブル スキャンの形式です。テーブル スキャンは特別なインデックスを使用せず、メモリ キャッシュ内の有用なものすべてをパージするのに役立ちます。たとえば、postgreSQL では、次のようになります。

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

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

于 2008-09-17T02:30:22.100 に答える
2

基本的に、各操作を調べて、操作がどのように機能するかについての知識を考慮して、操作が「理にかなっている」かどうかを確認します。

たとえば、A と B の 2 つのテーブルをそれぞれの列 C と D (AC=BD) で結合しており、計画でテーブルのクラスター化インデックス スキャン (SQL Server 用語 -- Oracle 用語は不明) が表示されているとします。 A の場合、テーブル B で一連のクラスター化されたインデックス シークに入れ子になったループ結合を行うと、問題が発生したと思われるかもしれません。そのシナリオでは、エンジンが 1 組のインデックス スキャン (結合された列のインデックスに対して) を実行した後、マージ結合を実行することを期待するかもしれません。さらに調査すると、オプティマイザがその結合パターンまたは実際には存在しないインデックスを選択する不適切な統計が明らかになる場合があります。

于 2008-09-17T02:31:32.253 に答える
2

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

于 2008-09-17T02:29:57.547 に答える
1

私は主にインデックスまたはテーブルのスキャンを探します。これは通常、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? 

これらを常に回避できるとは限りませんが、回避できるほど、クエリのパフォーマンスは向上します。

于 2008-09-17T02:33:39.333 に答える
1

計画の各サブセクションで費やされた時間の割合を見て、エンジンが何をしているかを検討してください。たとえば、テーブルをスキャンしている場合は、スキャン対象のフィールドにインデックスを配置することを検討してください。

于 2008-09-17T02:29:51.963 に答える
-7

経験則

(おそらく詳細についても読みたいと思うでしょう:

悪い

いくつかの大きなテーブルのテーブル スキャン

良い

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

最も一般的な勝利

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

于 2008-09-17T10:25:49.010 に答える