私はこれを非常に長くSQL command
しており、多くのステートメントがJOIN
あります。UNION
口を開いたが、、、、または意味Explain Plan Window
がわかりません。Cost
Cardinality
Bytes
誰かがそれらの用語を説明してもらえますか? そして、より低いことは必ずしもより速いquery
時間を意味しますか?
私はこれを非常に長くSQL command
しており、多くのステートメントがJOIN
あります。UNION
口を開いたが、、、、または意味Explain Plan Window
がわかりません。Cost
Cardinality
Bytes
誰かがそれらの用語を説明してもらえますか? そして、より低いことは必ずしもより速いquery
時間を意味しますか?
コストは、コストベースのクエリ オプティマイザーが適切な実行プランを選択するために行う見積もりです。通常、コストが低いほどクエリ時間が速くなりますが、常にそうとは限りません。
カーディナリティは、データベース統計に基づいて、クエリによって返されると予想される行数です。繰り返しますが、それは単なる見積もりです。
Bytesは、クエリの実行中にデータベースが読み取ると予想されるバイト数です。
オラクルのドキュメントでわかるように
CARDINALITY:操作によってアクセスされる行数のコストベースのアプローチによる見積もり。
BYTES:操作によってアクセスされるバイト数のコストベースのアプローチによる見積もり。
COST:オプティマイザのコストベースのアプローチによって見積もられた操作のコスト。ルールベースのアプローチを使用するステートメントの場合、この列は null です。テーブル アクセス操作のコストは決定されません。この列の値には、特定の測定単位はありません。これは、実行計画のコストを比較するために使用される加重値にすぎません。この列の値は、CPU_COST 列と IO_COST 列の関数です。
したがって、次のことも知っておく必要があります。
*CPU_COST:* オプティマイザのコストベースのアプローチによって推定される操作の CPU コスト。ルールベースのアプローチを使用するステートメントの場合、この列は null です。この列の値は、操作に必要なマシン サイクル数に比例します。
*IO_COST:* オプティマイザのコストベースのアプローチによって見積もられた操作の I/O コスト。ルールベースのアプローチを使用するステートメントの場合、この列は null です。この列の値は、操作によって読み取られたデータ ブロックの数に比例します。
Explain Plan は、データベースが使用する予定のプランを提供しますが、実際に使用されるプランは異なる可能性があることを知っておく必要があります。
クエリを最適化する場合、または他のクエリと比較してベンチマークする (最適なものを選択する) 場合は、実行時間、待機、再実行のサイズ、および論理 I/O を測定することから始めるのが適切です。私はExplain Planにあまり頼りません。
見て:
http://www.orafaq.com/wiki/SQL_Trace
と: