在子查询中逐级连接
[英]Connect By Level In Subquery Slow
问题描述
I am using a connect_by_level subquery in an Oracle database to supply dates to join with another table. 
我在Oracle数据库中使用connect_by_level子查询来提供与另一个表连接的日期。 The connect by level appears to be causing the query to run very slowly. 逐级连接似乎导致查询运行非常缓慢。 Here is my slow query: 这是我的慢查询：
select t.code, d.month_end, count(*)
from device t,
(select add_months(trunc(sysdate, 'MM'), - (level - 1)) - 1 MONTH_END
from dual
connect by level <= 1) d
where (d.month_end between t.date and t.exp_date)
group by t.code, d.month_end
The slow query above took about 2 hours to run the other day. 上面的慢查询花了大约2个小时来运行。 The query below which should be equivalent runs in less than 30 seconds: 下面的查询应该是等效的，运行时间不到30秒：
select t.code, trunc(sysdate, 'MM') - 1 month_end, count(*)
from device t
where ((trunc(sysdate, 'MM') - 1) between t.date and t.exp_date)
group by t.code
Ultimately, I want the 1st query to return data for the past 24 months, but I need to figure out why it is running so slowly with only 1 month as the criteria. 最终，我希望第一个查询返回过去24个月的数据，但我需要弄清楚为什么它运行得如此缓慢，只有1个月的标准。 Any suggestions on what is causing the slow completion time with the connect by level query? 有关通过级别查询连接导致缓慢完成时间的原因的任何建议？
Edit to add explain plan output for slow query: 编辑以添加缓慢查询的解释计划输出：
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 520 | 65520 | 134K (1)| 00:00:03 | | | | | |
| 1 | PX COORDINATOR | | | | | | | | | | |
| 2 | PX SEND QC (RANDOM) | :TQ10006 | 520 | 65520 | 134K (1)| 00:00:03 | | | Q1,06 | P->S | QC (RAND) |
| 3 | HASH GROUP BY | | 520 | 65520 | 134K (1)| 00:00:03 | | | Q1,06 | PCWP | |
| 4 | PX RECEIVE | | 520 | 65520 | 134K (1)| 00:00:03 | | | Q1,06 | PCWP | |
| 5 | PX SEND HASH | :TQ10005 | 520 | 65520 | 134K (1)| 00:00:03 | | | Q1,05 | P->P | HASH |
| 6 | HASH GROUP BY | | 520 | 65520 | 134K (1)| 00:00:03 | | | Q1,05 | PCWP | |
|* 7 | HASH JOIN OUTER | | 520 | 65520 | 134K (1)| 00:00:03 | | | Q1,05 | PCWP | |
| 8 | PX RECEIVE | | 520 | 48880 | 134K (1)| 00:00:03 | | | Q1,05 | PCWP | |
| 9 | PX SEND HASH | :TQ10003 | 520 | 48880 | 134K (1)| 00:00:03 | | | Q1,03 | P->P | HASH |
|* 10 | HASH JOIN OUTER BUFFERED | | 520 | 48880 | 134K (1)| 00:00:03 | | | Q1,03 | PCWP | |
| 11 | PX RECEIVE | | | | | | | | Q1,03 | PCWP | |
| 12 | PX SEND HASH | :TQ10001 | | | | | | | Q1,01 | P->P | HASH |
| 13 | NESTED LOOPS | | | | | | | | Q1,01 | PCWP | |
| 14 | NESTED LOOPS | | 276 | 13800 | 50303 (0)| 00:00:01 | | | Q1,01 | PCWP | |
| 15 | BUFFER SORT | | | | | | | | Q1,01 | PCWC | |
| 16 | PX RECEIVE | | | | | | | | Q1,01 | PCWP | |
| 17 | PX SEND BROADCAST | :TQ10000 | | | | | | | | S->P | BROADCAST |
| 18 | VIEW | | 1 | 6 | 3 (0)| 00:00:01 | | | | | |
|* 19 | CONNECT BY WITHOUT FILTERING| | | | | | | | | | |
| 20 | FAST DUAL | | 1 | | 3 (0)| 00:00:01 | | | | | |
| 21 | PX PARTITION RANGE ALL | | 3898K| | 1656 (0)| 00:00:01 | 1 | 75 | Q1,01 | PCWC | |
|* 22 | INDEX RANGE SCAN | FTR_DT_IX1 | 3898K| | 1656 (0)| 00:00:01 | 1 | 75 | Q1,01 | PCWP | |
|* 23 | TABLE ACCESS BY LOCAL INDEX ROWID| FTR_DT | 276 | 12144 | 50300 (0)| 00:00:01 | 1 | 1 | Q1,01 | PCWP | |
| 24 | PX RECEIVE | | 7344K| 308M| 83875 (1)| 00:00:02 | | | Q1,03 | PCWP | |
| 25 | PX SEND HASH | :TQ10002 | 7344K| 308M| 83875 (1)| 00:00:02 | | | Q1,02 | P->P | HASH |
| 26 | PX BLOCK ITERATOR | | 7344K| 308M| 83875 (1)| 00:00:02 | | | Q1,02 | PCWC | |
|* 27 | TABLE ACCESS STORAGE FULL | DTL_HIST_DT | 7344K| 308M| 83875 (1)| 00:00:02 | | | Q1,02 | PCWP | |
| 28 | PX RECEIVE | | 108K| 3376K| 275 (0)| 00:00:01 | | | Q1,05 | PCWP | |
| 29 | PX SEND HASH | :TQ10004 | 108K| 3376K| 275 (0)| 00:00:01 | | | Q1,04 | P->P | HASH |
| 30 | PX BLOCK ITERATOR | | 108K| 3376K| 275 (0)| 00:00:01 | | | Q1,04 | PCWC | |
|* 31 | TABLE ACCESS STORAGE FULL | POINT_T | 108K| 3376K| 275 (0)| 00:00:01 | | | Q1,04 | PCWP | |
Predicate Information (identified by operation id):
---------------------------------------------------
7 - access("C"."CODE"="AP"."CODE"(+) AND "C"."POINT_ID"="AP"."POINT_ID"(+))
10 - access("CF"."P_ID"="C"."WTN"(+))
19 - filter(LEVEL<=1)
22 - access("CF"."DATE"<=INTERNAL_FUNCTION("D"."MONTH_END"))
23 - filter(UPPER("CF"."PLAN") LIKE '%DV%' AND ("CF"."FT_CODE"='7370' OR "CF"."FT_CODE"='7371' OR "CF"."FT_CODE"='7372' OR
"CF"."FT_CODE"='7373' OR "CF"."FT_CODE"='7374' OR "CF"."FT_CODE"='7380' OR "CF"."FT_CODE"='7380C' OR "CF"."FT_CODE"='7381' OR
"CF"."FT_CODE"='7381C' OR "CF"."FT_CODE"='7382' OR "CF"."FT_CODE"='7382C' OR "CF"."FT_CODE"='7383' OR "CF"."FT_CODE"='7384' OR
"CF"."FT_CODE"='7409' OR "CF"."FT_CODE"='7409C' OR "CF"."FT_CODE"='7410' OR "CF"."FT_CODE"='7410C' OR "CF"."FT_CODE"='TRKDV') AND
"CF"."EXP_DATE">=INTERNAL_FUNCTION("D"."MONTH_END"))
27 - storage("C"."EXP_DATE"(+)>=TRUNC(SYSDATE@!,'fmmm')-1 AND "C"."DATE"(+)<=TRUNC(SYSDATE@!,'fmmm')-1)
filter("C"."EXP_DATE"(+)>=TRUNC(SYSDATE@!,'fmmm')-1 AND "C"."DATE"(+)<=TRUNC(SYSDATE@!,'fmmm')-1)
31 - storage("AP"."EXP_DATE"(+)>=TRUNC(SYSDATE@!,'fmmm')-1 AND "AP"."DATE"(+)<=TRUNC(SYSDATE@!,'fmmm')-1)
filter("AP"."EXP_DATE"(+)>=TRUNC(SYSDATE@!,'fmmm')-1 AND "AP"."DATE"(+)<=TRUNC(SYSDATE@!,'fmmm')-1)
Note
-----
- dynamic sampling used for this statement (level=6)
- automatic DOP: Computed Degree of Parallelism is 8
Edit to add explain plan for faster query: 编辑以添加解释计划以加快查询速度：
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
---------------------------------------------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 278 | 33360 | 622K (1)| 00:00:11 | | | | | |
| 1 | PX COORDINATOR | | | | | | | | | | |
| 2 | PX SEND QC (RANDOM) | :TQ10005 | 278 | 33360 | 622K (1)| 00:00:11 | | | Q1,05 | P->S | QC (RAND) |
| 3 | HASH GROUP BY | | 278 | 33360 | 622K (1)| 00:00:11 | | | Q1,05 | PCWP | |
| 4 | PX RECEIVE | | 4034 | 472K| 622K (1)| 00:00:11 | | | Q1,05 | PCWP | |
| 5 | PX SEND HASH | :TQ10004 | 4034 | 472K| 622K (1)| 00:00:11 | | | Q1,04 | P->P | HASH |
|* 6 | HASH JOIN OUTER BUFFERED | | 4034 | 472K| 622K (1)| 00:00:11 | | | Q1,04 | PCWP | |
| 7 | PX RECEIVE | | 4034 | 346K| 621K (1)| 00:00:11 | | | Q1,04 | PCWP | |
| 8 | PX SEND HASH | :TQ10002 | 4034 | 346K| 621K (1)| 00:00:11 | | | Q1,02 | P->P | HASH |
|* 9 | HASH JOIN OUTER BUFFERED | | 4034 | 346K| 621K (1)| 00:00:11 | | | Q1,02 | PCWP | |
| 10 | PX RECEIVE | | 2140 | 94160 | 538K (1)| 00:00:09 | | | Q1,02 | PCWP | |
| 11 | PX SEND HASH | :TQ10000 | 2140 | 94160 | 538K (1)| 00:00:09 | | | Q1,00 | P->P | HASH |
| 12 | PX BLOCK ITERATOR | | 2140 | 94160 | 538K (1)| 00:00:09 | 1 | 75 | Q1,00 | PCWC | |
|* 13 | TABLE ACCESS STORAGE FULL| FTR_DT | 2140 | 94160 | 538K (1)| 00:00:09 | 1 | 75 | Q1,00 | PCWP | |
| 14 | PX RECEIVE | | 7344K| 308M| 83875 (1)| 00:00:02 | | | Q1,02 | PCWP | |
| 15 | PX SEND HASH | :TQ10001 | 7344K| 308M| 83875 (1)| 00:00:02 | | | Q1,01 | P->P | HASH |
| 16 | PX BLOCK ITERATOR | | 7344K| 308M| 83875 (1)| 00:00:02 | | | Q1,01 | PCWC | |
|* 17 | TABLE ACCESS STORAGE FULL| DTL_HIST_DT | 7344K| 308M| 83875 (1)| 00:00:02 | | | Q1,01 | PCWP | |
| 18 | PX RECEIVE | | 108K| 3376K| 275 (0)| 00:00:01 | | | Q1,04 | PCWP | |
| 19 | PX SEND HASH | :TQ10003 | 108K| 3376K| 275 (0)| 00:00:01 | | | Q1,03 | P->P | HASH |
| 20 | PX BLOCK ITERATOR | | 108K| 3376K| 275 (0)| 00:00:01 | | | Q1,03 | PCWC | |
|* 21 | TABLE ACCESS STORAGE FULL | POINT_T | 108K| 3376K| 275 (0)| 00:00:01 | | | Q1,03 | PCWP | |
Predicate Information (identified by operation id):
---------------------------------------------------
6 - access("C"."CODE"="AP"."CODE"(+) AND "C"."POINT_ID"="AP"."POINT_ID"(+))
9 - access("CF"."P_ID"="C"."WTN"(+))
13 - storage(UPPER("CF"."PLAN") LIKE '%DV%' AND ("CF"."FT_CODE"='7370' OR "CF"."FT_CODE"='7371' OR "CF"."FT_CODE"='7372' OR
"CF"."FT_CODE"='7373' OR "CF"."FT_CODE"='7374' OR "CF"."FT_CODE"='7380' OR "CF"."FT_CODE"='7380C' OR "CF"."FT_CODE"='7381' OR
"CF"."FT_CODE"='7381C' OR "CF"."FT_CODE"='7382' OR "CF"."FT_CODE"='7382C' OR "CF"."FT_CODE"='7383' OR "CF"."FT_CODE"='7384'
OR "CF"."FT_CODE"='7409' OR "CF"."FT_CODE"='7409C' OR "CF"."FT_CODE"='7410' OR "CF"."FT_CODE"='7410C' OR
"CF"."FT_CODE"='TRKDV') AND "CF"."EXP_DATE">=TRUNC(SYSDATE@!,'fmmm')-1 AND "CF"."DATE"<=TRUNC(SYSDATE@!,'fmmm')-1)
filter(UPPER("CF"."PLAN") LIKE '%DV%' AND ("CF"."FT_CODE"='7370' OR "CF"."FT_CODE"='7371' OR "CF"."FT_CODE"='7372' OR
"CF"."FT_CODE"='7373' OR "CF"."FT_CODE"='7374' OR "CF"."FT_CODE"='7380' OR "CF"."FT_CODE"='7380C' OR "CF"."FT_CODE"='7381' OR
"CF"."FT_CODE"='7381C' OR "CF"."FT_CODE"='7382' OR "CF"."FT_CODE"='7382C' OR "CF"."FT_CODE"='7383' OR "CF"."FT_CODE"='7384'
OR "CF"."FT_CODE"='7409' OR "CF"."FT_CODE"='7409C' OR "CF"."FT_CODE"='7410' OR "CF"."FT_CODE"='7410C' OR
"CF"."FT_CODE"='TRKDV') AND "CF"."EXP_DATE">=TRUNC(SYSDATE@!,'fmmm')-1 AND "CF"."DATE"<=TRUNC(SYSDATE@!,'fmmm')-1)
17 - storage("C"."EXP_DATE"(+)>=TRUNC(SYSDATE@!,'fmmm')-1 AND "C"."DATE"(+)<=TRUNC(SYSDATE@!,'fmmm')-1)
filter("C"."EXP_DATE"(+)>=TRUNC(SYSDATE@!,'fmmm')-1 AND "C"."DATE"(+)<=TRUNC(SYSDATE@!,'fmmm')-1)
21 - storage("AP"."EXP_DATE"(+)>=TRUNC(SYSDATE@!,'fmmm')-1 AND "AP"."DATE"(+)<=TRUNC(SYSDATE@!,'fmmm')-1)
filter("AP"."EXP_DATE"(+)>=TRUNC(SYSDATE@!,'fmmm')-1 AND "AP"."DATE"(+)<=TRUNC(SYSDATE@!,'fmmm')-1)
Note
-----
- dynamic sampling used for this statement (level=6)
- automatic DOP: Computed Degree of Parallelism is 8
1 个解决方案
解决方案1
0 2013-10-22 19:17:29
In first query Oracle is doing an index range scan on a large table and retrieving huge amounts of data on the first pass with access("CF"."DATE"<=INTERNAL_FUNCTION("D"."MONTH_END")). 在第一个查询中，Oracle正在大型表上进行索引范围扫描，并在第一次access("CF"."DATE"<=INTERNAL_FUNCTION("D"."MONTH_END")).检索大量数据access("CF"."DATE"<=INTERNAL_FUNCTION("D"."MONTH_END")). You can work around it by rewriting your select to be more like your fast one. 您可以通过重写您的选择来更好地解决它。 It would be something like this - 它会是这样的 -
select t.code, trunc(t.exp_date, 'MM') - 1 month_end, count(*)
from device t
where t.date < :report_period_end
and t.exp_date > :report_period_start
group by t.code, trunc(t.exp_date,'MM') - 1;
Also note that there are several potential problems with your original slow query: 另请注意，原始慢查询存在一些潜在问题：
- A row where t.date and t.exp_date is more than 2 months apart will be counted multiple times. t.date和t.exp_date相隔超过2个月的行将被计数多次。
- Rows where t.date and t.exp_date has the same month will not be counted at all t.date和t.exp_date具有相同月份的行将不计算在内
- You are comparing your dates to eg 2013.10.30 00:00:00. 您正在比较您的日期，例如2013.10.30 00:00:00。 Results may be incorrect if your dates contain time data. 如果您的日期包含时间数据，结果可能不正确。
声明:本站的技术帖子网页，遵循CC BY-SA 4.0协议，如果您需要转载，请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.
相关问题
使用 CONNECT BY LEVEL 时查询非常慢 - Very slow query when using CONNECT BY LEVEL
子查询很慢 - Subquery is slow
慢的mysql子查询 - Slow mysql subquery
mysql子查询极其缓慢 - mysql subquery extremely slow
慢从属子查询的问题 - Problems with a slow Dependent Subquery
mysql子查询奇怪的慢 - mysql subquery strangely slow
子查询的使用非常慢 - Usage of Subquery very slow
慢子查询IN子句？ - Slow subquery IN clause?
视图中的子查询运行缓慢 - Subquery in view runs slow
SQL-慢子查询 - SQL - Slow subquery
相关标签