Irf*_*rfy 8 oracle oracle-11g-r2 partitioning group-by
(当只涉及两个表时,oracle 的优化器对两种方法执行相同的操作,因此我的问题涉及三个表)
假设三个表t1
,t2
并t3
与成对1:n
由左到右的关系:
t1 (1)--(n) t2 (1)--(n) t3
Run Code Online (Sandbox Code Playgroud)
每个分区p
在所有连接中使用的公共列上,每个分区都有一个主键id
、外键t2.id1 -> t1.id
和t3.id2 -> t2.id
.
实际上,n
(两者)都很小。可能t2
每t1
行大约 2t3
行,从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
Run Code Online (Sandbox Code Playgroud)
它给出t3
每t2
行的行数并将t1
数据连接到它。你可以想象得到以下输出:
t1id t2id t3count
---- ---- -------
1 1 3
1 2 1
1 3 2
2 4 5
3 5 1
3 6 1
Run Code Online (Sandbox Code Playgroud)
现在将此查询与:
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)
Run Code Online (Sandbox Code Playgroud)
(后者可以用嵌套select
而不是编写with
)。
在这里,我基本上将t3
表预先分组,然后将其与其他两个表连接。
第一个选择在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|
------------------------------------------------------------------------------------------------------
Run Code Online (Sandbox Code Playgroud)
优化器决定先连接 t1 和 t3,否则不会出现意外。
第二个查询给出了以下计划:
----------------------------------------------------------------------------------------------------------------
| 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|
----------------------------------------------------------------------------------------------------------------
Run Code Online (Sandbox Code Playgroud)
现在,这里的优化第一组t3
的指示,然后加入t1
和t2
再利用分区加入分组t3
与加盟t1-t2
。
如果我添加一个 where 子句限制 by t1.id
,我会得到以下类似的计划:
首先选择:
---------------------------------------------------------------------------------------------------------------
| 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 |
---------------------------------------------------------------------------------------------------------------
Run Code Online (Sandbox Code Playgroud)
二选:
-----------------------------------------------------------------------------------------------------------------
| 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 |
-----------------------------------------------------------------------------------------------------------------
Run Code Online (Sandbox Code Playgroud)
虽然我模糊地了解优化器在做什么,但我无法断定哪个查询更好。计划中是否有一些明显的东西应该指示我更喜欢一个查询而不是另一个,或者它们在性能方面看起来相当相似?
关于限制的注意事项t1.id
:为了简单起见,我简化了表的描述和它们之间的关系。从这个意义上说,过滤 by 似乎t1.id
没有性能,t3
因为它显然没有包含t1.id
. 在现实中,t2
是一个弱实体,主键(t1.id, t2.id)
和t3
外键的指向t2
完全一样,包括t1.id
. 这就是为什么t3fk
在上面的最后两个计划中进行索引范围扫描的原因。
优化器总是尝试尽快减少数据量。如果没有,你的统计数据可能不好。
您的计划 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 |
---------------------------------------------------------------------------------------------------------------
Run Code Online (Sandbox Code Playgroud)
它表明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 |
-----------------------------------------------------------------------------------------------------------------
Run Code Online (Sandbox Code Playgroud)
结论:在大多数情况下,我更喜欢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)
Run Code Online (Sandbox Code Playgroud)
归档时间: |
|
查看次数: |
14066 次 |
最近记录: |