グループ化してから参加するか、参加してからグループ化する必要がありますか？
（Oracleのオプティマイザは、2つのテーブルのみが関係する場合、両方のアプローチで同じことを行うため、私の質問には3つのテーブルが関係します）
3つのテーブルt1、t2、およびt3を、左から右にペアの1:n関係で想定します。
t1 (1)--(n) t2 (1)--(n) t3
すべてがすべての結合で使用される共通の列pで分割され、それぞれが主キーidを持ち、外部キーt2.id1 -> t1.idおよびt3.id2 -> t2.idを持ちます。
実際には、n（どちらも）は小さいです。おそらく、各t2行に約2 t1行、t3の各行に約3 t2行あります。
これらのテーブルを次のように結合したいと思います。
select t1.id t1id, t2.id t2id, count(1) t3count
from t1 join t2 on (t1.p = t2.p and t1.id = t2.id1)
join t3 on (t2.p = t3.p and t2.id = t3.id2)
group by t1.id, t2.id
各t3行のt2行の数を示し、t1データをそれに結合します。次の出力が得られると想像できます。
t1id t2id t3count
---- ---- -------
1 1 3
1 2 1
1 3 2
2 4 5
3 5 1
3 6 1
次に、このクエリを次と比較します。
with t3g as ( -- as in 't3 grouped'
select id2, count(1) t3count
from t3
group by id2
)
select t1.id t1id, t2id, t3count
from t1 join t2 on (t1.p = t2.p and t1.id = t2.id1)
join t3g on (t2.p = t3g.p and t2.id = id2)
（この後者は、selectの代わりにネストされたwithで記述されている可能性があります）。
ここでは、基本的にt3テーブルを事前にグループ化し、それを他の2つのテーブルと結合します。
最初の選択により、Oracleで次の計画が得られます。
------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | Pstart| Pstop |
------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 69578 | 5367K| | 2363 (1)| 00:00:01 | | |
| 1 | PARTITION RANGE ALL | | 69578 | 5367K| | 2363 (1)| 00:00:01 | 1 |1048575|
| 2 | HASH GROUP BY | | 69578 | 5367K| 6336K| 2363 (1)| 00:00:01 | | |
|* 3 | HASH JOIN | | 69578 | 5367K| | 1083 (2)| 00:00:01 | | |
| 4 | TABLE ACCESS FULL | t2 | 81635 | 1275K| | 256 (1)| 00:00:01 | 1 |1048575|
|* 5 | HASH JOIN | | 70033 | 4308K| | 823 (1)| 00:00:01 | | |
| 6 | TABLE ACCESS FULL| t1 | 81622 | 1753K| | 616 (1)| 00:00:01 | 1 |1048575|
| 7 | TABLE ACCESS FULL| t3 | 70033 | 2804K| | 204 (1)| 00:00:01 | 1 |1048575|
------------------------------------------------------------------------------------------------------
オプティマイザは最初にt1とt3を結合することを決定します。そうでない場合、予期しないことは何もありません。
2番目のクエリは、次の計画を提供します。
----------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | Pstart| Pstop |
----------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 69578 | 21M| | 3125 (1)| 00:00:01 | | |
|* 1 | HASH JOIN | | 69578 | 21M| 8144K| 3125 (1)| 00:00:01 | | |
| 2 | PART JOIN FILTER CREATE | :BF0000 | 70033 | 7317K| | 950 (1)| 00:00:01 | | |
| 3 | VIEW | | 70033 | 7317K| | 950 (1)| 00:00:01 | | |
| 4 | HASH GROUP BY | | 70033 | 2804K| 4424K| 950 (1)| 00:00:01 | | |
| 5 | PARTITION RANGE ALL | | 70033 | 2804K| | 204 (1)| 00:00:01 | 1 |1048575|
| 6 | TABLE ACCESS FULL | t3 | 70033 | 2804K| | 204 (1)| 00:00:01 | 1 |1048575|
| 7 | PARTITION RANGE JOIN-FILTER| | 81622 | 17M| | 876 (1)| 00:00:01 |:BF0000|:BF0000|
|* 8 | HASH JOIN | | 81622 | 17M| | 876 (1)| 00:00:01 | | |
| 9 | TABLE ACCESS FULL | t2 | 81635 | 4623K| | 256 (1)| 00:00:01 |:BF0000|:BF0000|
| 10 | TABLE ACCESS FULL | t1 | 81622 | 12M| | 616 (1)| 00:00:01 |:BF0000|:BF0000|
----------------------------------------------------------------------------------------------------------------
ここで、オプティマイザは最初にt3を指示どおりにグループ化し、次にt1とt2を結合し、パーティショニングを使用して、グループ化されたt3と結合されたt1-t2を結合します。
t1.idで制限するwhere句を追加すると、次のような、かなり似た計画が得られます。
最初に選択：
---------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
---------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 79 | 7 (15)| 00:00:01 | | |
| 1 | HASH GROUP BY | | 1 | 79 | 7 (15)| 00:00:01 | | |
| 2 | NESTED LOOPS | | | | | | | |
| 3 | NESTED LOOPS | | 1 | 79 | 6 (0)| 00:00:01 | | |
| 4 | NESTED LOOPS | | 1 | 63 | 5 (0)| 00:00:01 | | |
| 5 | TABLE ACCESS BY GLOBAL INDEX ROWID| t1 | 1 | 22 | 3 (0)| 00:00:01 | ROWID | ROWID |
|* 6 | INDEX RANGE SCAN | t1pk | 1 | | 2 (0)| 00:00:01 | | |
| 7 | PARTITION RANGE ITERATOR | | 1 | 41 | 2 (0)| 00:00:01 | KEY | KEY |
|* 8 | TABLE ACCESS BY LOCAL INDEX ROWID| t3 | 1 | 41 | 2 (0)| 00:00:01 | KEY | KEY |
|* 9 | INDEX RANGE SCAN | t3fk | 1 | | 1 (0)| 00:00:01 | KEY | KEY |
|* 10 | INDEX UNIQUE SCAN | t2pk | 1 | | 0 (0)| 00:00:01 | | |
|* 11 | TABLE ACCESS BY GLOBAL INDEX ROWID | t2 | 1 | 16 | 1 (0)| 00:00:01 | ROWID | ROWID |
---------------------------------------------------------------------------------------------------------------
2番目の選択：
-----------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
-----------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 311 | 7 (15)| 00:00:01 | | |
| 1 | NESTED LOOPS | | | | | | | |
| 2 | NESTED LOOPS | | 1 | 311 | 7 (15)| 00:00:01 | | |
| 3 | NESTED LOOPS | | 1 | 253 | 6 (17)| 00:00:01 | | |
| 4 | TABLE ACCESS BY GLOBAL INDEX ROWID | t1 | 1 | 164 | 3 (0)| 00:00:01 | ROWID | ROWID |
|* 5 | INDEX RANGE SCAN | t1pk | 1 | | 2 (0)| 00:00:01 | | |
| 6 | VIEW PUSHED PREDICATE | | 1 | 89 | 3 (34)| 00:00:01 | | |
| 7 | SORT GROUP BY | | 1 | 41 | 3 (34)| 00:00:01 | | |
|* 8 | FILTER | | | | | | | |
| 9 | PARTITION RANGE SINGLE | | 1 | 41 | 2 (0)| 00:00:01 | KEY | KEY |
|* 10 | TABLE ACCESS BY LOCAL INDEX ROWID| t3 | 1 | 41 | 2 (0)| 00:00:01 | KEY | KEY |
|* 11 | INDEX RANGE SCAN | t3fk | 1 | | 1 (0)| 00:00:01 | KEY | KEY |
|* 12 | INDEX UNIQUE SCAN | t2pk | 1 | | 0 (0)| 00:00:01 | | |
|* 13 | TABLE ACCESS BY GLOBAL INDEX ROWID | t2 | 1 | 58 | 1 (0)| 00:00:01 | ROWID | ROWID |
-----------------------------------------------------------------------------------------------------------------
オプティマイザが何をしているかは漠然と理解していますが、どのクエリが優れているかを結論付けることはできません。あるクエリを他のクエリよりも優先するように指示するべきである計画に明白な何かがありますか、それともそれらはパフォーマンスに関してかなり同等に見えますか？
t1.idによる制限についての注記：簡単にするために、テーブルの説明とテーブル間の関係を簡略化しました。この意味で、t1.idを含むインデックスはt3を含んでいるように見えないため、t1.idによるフィルタリングはt2に対してパフォーマンスが悪いように見えるかもしれません。実際には、(t1.id, t2.id)はweak entityであり、プライマリキーt3とt2へのt1.idへの外部キーは、_ [を含めてまったく同じです。 SOMECODE] _。上記の最後の2つのプランでt3fkにインデックス範囲スキャンがあるのはそのためです。
オプティマイザは常に、可能な限り迅速にデータ量を削減しようとします。そうでなければ、あなたの統計は良くないかもしれません。
計画1は、処理される行が少ないことを示しています。これは良いことです。オプティマイザーは、データ量をより迅速に削減することができました。数値は正確には当てはまらない場合がありますが、オプティマイザ統計に基づいたアイデアを提供します。
計画1：
---------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
---------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 79 | 7 (15)| 00:00:01 | | |
| 1 | HASH GROUP BY | | 1 | 79 | 7 (15)| 00:00:01 | | |
| 2 | NESTED LOOPS | | | | | | | |
| 3 | NESTED LOOPS | | 1 | 79 | 6 (0)| 00:00:01 | | |
| 4 | NESTED LOOPS | | 1 | 63 | 5 (0)| 00:00:01 | | |
| 5 | TABLE ACCESS BY GLOBAL INDEX ROWID| t1 | 1 | 22 | 3 (0)| 00:00:01 | ROWID | ROWID |
|* 6 | INDEX RANGE SCAN | t1pk | 1 | | 2 (0)| 00:00:01 | | |
| 7 | PARTITION RANGE ITERATOR | | 1 | 41 | 2 (0)| 00:00:01 | KEY | KEY |
|* 8 | TABLE ACCESS BY LOCAL INDEX ROWID| t3 | 1 | 41 | 2 (0)| 00:00:01 | KEY | KEY |
|* 9 | INDEX RANGE SCAN | t3fk | 1 | | 1 (0)| 00:00:01 | KEY | KEY |
|* 10 | INDEX UNIQUE SCAN | t2pk | 1 | | 0 (0)| 00:00:01 | | |
|* 11 | TABLE ACCESS BY GLOBAL INDEX ROWID | t2 | 1 | 16 | 1 (0)| 00:00:01 | ROWID | ROWID |
---------------------------------------------------------------------------------------------------------------
これは、OracleがHASH GROUP BYを実行したのに対し、プラン2はSORT GROUP BY。
-----------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
-----------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 311 | 7 (15)| 00:00:01 | | |
| 1 | NESTED LOOPS | | | | | | | |
| 2 | NESTED LOOPS | | 1 | 311 | 7 (15)| 00:00:01 | | |
| 3 | NESTED LOOPS | | 1 | 253 | 6 (17)| 00:00:01 | | |
| 4 | TABLE ACCESS BY GLOBAL INDEX ROWID | t1 | 1 | 164 | 3 (0)| 00:00:01 | ROWID | ROWID |
|* 5 | INDEX RANGE SCAN | t1pk | 1 | | 2 (0)| 00:00:01 | | |
| 6 | VIEW PUSHED PREDICATE | | 1 | 89 | 3 (34)| 00:00:01 | | |
| 7 | SORT GROUP BY | | 1 | 41 | 3 (34)| 00:00:01 | | |
|* 8 | FILTER | | | | | | | |
| 9 | PARTITION RANGE SINGLE | | 1 | 41 | 2 (0)| 00:00:01 | KEY | KEY |
|* 10 | TABLE ACCESS BY LOCAL INDEX ROWID| t3 | 1 | 41 | 2 (0)| 00:00:01 | KEY | KEY |
|* 11 | INDEX RANGE SCAN | t3fk | 1 | | 1 (0)| 00:00:01 | KEY | KEY |
|* 12 | INDEX UNIQUE SCAN | t2pk | 1 | | 0 (0)| 00:00:01 | | |
|* 13 | TABLE ACCESS BY GLOBAL INDEX ROWID | t2 | 1 | 58 | 1 (0)| 00:00:01 | ROWID | ROWID |
-----------------------------------------------------------------------------------------------------------------
結論：ほとんどの場合、HASH GROUP BYを使用します。したがって、計画1では、Oracleはずっと少ないデータでGROUP BYをより適切に実行します。計画1の方が優れている2つの理由。
これは、この結合コンステレーションを使用する唯一のSQLステートメントではないと思います。 SQLごとにどちらの方法が最適かを決定する必要があります。
次のようなSQLがある場合は、with句の方がはるかに優れています。
with t3g as ( -- as in 't3 grouped'
select id2, count(1) t3count
from t3
where id = :1 -- new line !!!!!!!!
group by id2
)
select t1.id t1id, t2id, t3count
from t1 join t2 on (t1.p = t2.p and t1.id = t2.id1)
join t3g on (t2.p = t3g.p and t2.id = id2)
最初のクエリでパーティション列を省略すると、インデックスからクエリを完全に完了することができるはずです。これはかなり速くなるはずです。
この例では、t3からキー列を使用できるはずなので、t1とt2を削除します。これはかなり速くなるはずです。
T1やt2からのデータが必要な場合は、それらをt3に結合します。 t1.idではなくt3.idに制限する場合は、計画を確認してください。
制限句のないプランは通常、全テーブルスキャンを使用します。これは、すべての行にアクセスする最も速い方法である傾向があります。この計画は、制限条項のある計画とは大幅に異なる場合があります。
オプティマイザは、データにアクセスするコストを制限しようとします。次のルールが適用される場合があります。
- 行の数パーセント以上にアクセスする必要がある場合のテーブルスキャン。
- 最初に最小の結果セットを選択します。
- すべての列がインデックス内にある場合、テーブルではなくインデックスからデータにアクセスします。