基于UNION ALL的分页查询执行计划问题(二)

今天又发现9204上的一个问题。不过这个问题并不会造成数据的错误,但是会严重的影响查询的性能。

基于UNION ALL的分页查询执行计划问题:http://yangtingkun.itpub.net/post/468/303221

这篇文章继续讨论这个问题,并给出一个相对简单的解决方法。

首先发现的第一个问题是,这个问题是由UNION ALL引起的,而和视图没有关系。

SQL> SELECT *
2 FROM
3 (
4 SELECT ROWNUM RN, A.*
5 FROM
6 (
7 SELECT /*+ FIRST_ROWS */ * FROM V_T
8 WHERE CREATE_DATE = SYSDATE - 2
9 ) A
10 WHERE ROWNUM <= 10
11 )
12 WHERE RN > 1
13 ;

未选定行

执行计划
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=HINT: FIRST_ROWS (Cost=11 Card=10 Bytes=520)
1 0 VIEW (Cost=11 Card=10 Bytes=520)
2 1 COUNT (STOPKEY)
3 2 VIEW OF 'V_T' (Cost=11 Card=14885 Bytes=580515)
4 3 UNION-ALL
5 4 TABLE ACCESS (FULL) OF 'T1' (Cost=9 Card=13727 Bytes=480445)
6 4 TABLE ACCESS (FULL) OF 'T2' (Cost=2 Card=1158 Bytes=35898)

SQL> SELECT *
2 FROM
3 (
4 SELECT ROWNUM RN, A.*
5 FROM
6 (
7 SELECT /*+ FIRST_ROWS */ * FROM
8 (
9 SELECT * FROM T1
10 UNION ALL
11 SELECT * FROM T2
12 )
13 WHERE CREATE_DATE = SYSDATE - 2
14 ) A
15 WHERE ROWNUM <= 10
16 )
17 WHERE RN > 1
18 ;

未选定行

执行计划
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=HINT: FIRST_ROWS (Cost=11 Card=10 Bytes=520)
1 0 VIEW (Cost=11 Card=10 Bytes=520)
2 1 COUNT (STOPKEY)
3 2 VIEW (Cost=11 Card=14885 Bytes=580515)
4 3 UNION-ALL
5 4 TABLE ACCESS (FULL) OF 'T1' (Cost=9 Card=13727 Bytes=480445)
6 4 TABLE ACCESS (FULL) OF 'T2' (Cost=2 Card=1158 Bytes=35898)

在Metalink上搜索了一下,没有找到这个问题的描述,不过似乎和下面这个问题有几分类似:Note:2281909.8。

Description

Suboptimal plan possible from INLINE non-correlated UNION ALL subquery. When this problem occurs the execution plan indicates that the subquery has been unnested to a view, and a join predicate was pushed into the view.

这个bug中的问题是由于Oracle错误的将连接列的查询条件推入到UNION ALL子查询中,导致性能下降。而当前的问题是Oracle没有把限制条件推入到UNION ALL子查询中去。

对于这个问题的解决,就是避免在ROWNUM出现后,在外层再嵌套一层查询。

当然升级到10g也是一种选择,不过代价比较大。

对于分页操作由于无法避免三层嵌套查询,可以利用MINUS来解决这个问题:

SQL> SELECT ROWNUM, A.*
2 FROM
3 (
4 SELECT /*+ FIRST_ROWS */ * FROM V_T
5 WHERE CREATE_DATE = SYSDATE - 2
6 ORDER BY NAME
7 ) A
8 WHERE ROWNUM <= 20
9 MINUS
10 SELECT ROWNUM, A.*
11 FROM
12 (
13 SELECT /*+ FIRST_ROWS */ * FROM V_T
14 WHERE CREATE_DATE = SYSDATE - 2
15 ORDER BY NAME
16 ) A
17 WHERE ROWNUM <= 10
18 ;

未选定行

执行计划
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=HINT: FIRST_ROWS (Cost=18 Card=20 Bytes=1170)
1 0 MINUS
2 1 SORT (UNIQUE) (Cost=9 Card=20 Bytes=780)
3 2 COUNT (STOPKEY)
4 3 VIEW (Cost=7 Card=21 Bytes=819)
5 4 SORT (ORDER BY STOPKEY) (Cost=7 Card=21 Bytes=777)
6 5 VIEW OF 'V_T' (Cost=4 Card=21 Bytes=777)
7 6 UNION-ALL (PARTITION)
8 7 TABLE ACCESS (BY INDEX ROWID) OF 'T1' (Cost=4 Card=35 Bytes=1225)
9 8 INDEX (RANGE SCAN) OF 'IND_T1_CREATE_DATE' (NON-UNIQUE) (Cost=1 Card=35)
10 7 TABLE ACCESS (BY INDEX ROWID) OF 'T2' (Cost=3 Card=2 Bytes=62)
11 10 INDEX (RANGE SCAN) OF 'IND_T2_CREATE_DATE' (NON-UNIQUE) (Cost=1 Card=2)
12 1 SORT (UNIQUE) (Cost=9 Card=10 Bytes=390)
13 12 COUNT (STOPKEY)
14 13 VIEW (Cost=7 Card=21 Bytes=819)
15 14 SORT (ORDER BY STOPKEY) (Cost=7 Card=21 Bytes=777)
16 15 VIEW OF 'V_T' (Cost=4 Card=21 Bytes=777)
17 16 UNION-ALL (PARTITION)
18 17 TABLE ACCESS (BY INDEX ROWID) OF 'T1' (Cost=4 Card=35 Bytes=1225)
19 18 INDEX (RANGE SCAN) OF 'IND_T1_CREATE_DATE' (NON-UNIQUE) (Cost=1 Card=35)
20 17 TABLE ACCESS (BY INDEX ROWID) OF 'T2' (Cost=3 Card=2 Bytes=62)
21 20 INDEX (RANGE SCAN) OF 'IND_T2_CREATE_DATE' (NON-UNIQUE) (Cost=1 Card=2)

采用这种方式,可以在利用索引的基础上完成翻页的功能,不过这种方法对于结果集靠后的记录可能会导致查询时间成倍增加。

使用这个方法一般只在下面两个条件都成立:

已经碰到了基于UNION ALL的查询不走索引的情况;

索引查询的选择度比较高,能够确保过滤掉绝大部分的数据。

时间: 2024-09-26 12:46:56

基于UNION ALL的分页查询执行计划问题(二)的相关文章

基于UNION ALL的分页查询执行计划问题

今天又发现9204上的一个问题.不过这个问题并不会造成数据的错误,但是会严重的影响查询的性能. 还是通过一个简单的例子来展现问题: SQL> CREATE TABLE T1 (ID NUMBER, NAME VARCHAR2(30), CREATE_DATE DATE); 表已创建. SQL> CREATE INDEX IND_T1_CREATE_DATE ON T1(CREATE_DATE); 索引已创建. SQL> CREATE TABLE T2 (ID NUMBER, NAME V

浅析SQL Server的聚焦使用索引和查询执行计划_MsSql

前言 上一篇<浅析SQL Server 聚焦索引对非聚集索引的影响>我们讲了聚集索引对非聚集索引的影响,对数据库一直在强调的性能优化,所以这一节我们统筹讲讲利用索引来看看查询执行计划是怎样的,简短的内容,深入的理解. 透过索引来看查询执行计划 我们首先来看看第一个例子 1.默认使用索引 USE TSQL2012 GO SELECT orderid FROM Sales.Orders SELECT * FROM Sales.Orders 上述我们看到第2个查询的所需要的开销是第1个查询开销的3倍

SQL Server-聚焦使用索引和查询执行计划(五)

前言 上一篇我们讲了聚集索引对非聚集索引的影响,对数据库一直在强调的性能优化,所以这一节我们统筹讲讲利用索引来看看查询执行计划是怎样的,简短的内容,深入的理解,Always to review the basics. 透过索引来看查询执行计划 我们首先来看看第一个例子 1.默认使用索引 USE TSQL2012 GO SELECT orderid FROM Sales.Orders SELECT * FROM Sales.Orders 上述我们看到第2个查询的所需要的开销是第1个查询开销的3倍,

浅析SQL Server的聚焦使用索引和查询执行计划

前言 上一篇<浅析SQL Server 聚焦索引对非聚集索引的影响>我们讲了聚集索引对非聚集索引的影响,对数据库一直在强调的性能优化,所以这一节我们统筹讲讲利用索引来看看查询执行计划是怎样的,简短的内容,深入的理解. 透过索引来看查询执行计划 我们首先来看看第一个例子 1.默认使用索引 USE TSQL2012 GO SELECT orderid FROM Sales.Orders SELECT * FROM Sales.Orders 上述我们看到第2个查询的所需要的开销是第1个查询开销的3倍

Oracle分页查询格式(十二)

Oracle的分页查询语句基本上可以按照本文给出的格式来进行套用. 这篇介绍分析函数用于分页,且排序字段上包含索引的情况. Oracle分页查询格式(一):http://yangtingkun.itpub.net/post/468/100278 Oracle分页查询格式(二):http://yangtingkun.itpub.net/post/468/101703 Oracle分页查询格式(三):http://yangtingkun.itpub.net/post/468/104595 Oracl

一个执行计划异常变更的案例 - 外传之查询执行计划的几种方法

之前的几篇文章: <一个执行计划异常变更的案例 - 前传> <一个执行计划异常变更的案例 - 外传之绑定变量窥探> <一个执行计划异常变更的案例 - 外传之查看绑定变量值的几种方法> <一个执行计划异常变更的案例 - 外传之rolling invalidation> <一个执行计划异常变更的案例 - 外传之聚簇因子(Clustering Factor)> 本篇外传主要介绍一些常用的执行计划查看方法. SQL的执行计划实际代表了目标SQL在Orac

高性能的MySQL(6)查询执行机制(二)

这里继续上一篇中的优化器部分: MySQL如何执行关联查询 MySQL对任何关联都执行嵌套循环关联操作,即先在一个表中循环取出单条数据,然后再嵌套循环到下一个表中寻找匹配的行,依次下去,直到找到所有表中匹配的行为止.然后根据各个表匹配的行,返回查询中需要的各个列.MySQL会尝试在最后一个关联表中找到所有匹配的行,如果最后一个关联表无法找到更多的行以后,MySQL返回到上一层次关联表,看是否能够找到更多的匹配记录,依次类推迭代执行. 例如: select tab1.col1,tab2.col2

分页查询的排序问题(二)

在第一篇文章中介绍过了,当对全表扫描执行ORDER BY STOPKEY操作时,如果排序列是不唯一的,那么排序结果是不稳定的. 正好PUB上有个帖子在讨论这个问题,这里就简单描述一下对Oracle排序的一点研究.PUB上的原贴:http://www.itpub.net/showthread.php?s=&threadid=850977 分页查询的排序问题:http://yangtingkun.itpub.net/post/468/112274 为了描述问题,首先要再现问题.为了更好的说明问题,在

Oracle 11g r2全外连接优化执行计划(二) 新增的两个相关的HINT

Oracle在推出了新的执行计划的同时,还提供了两个控制这个执行计划的提示NATIVE_FULL_OUTER_JOIN和NO_NATIVE_FULL_OUTER_JOIN. 这两个HINT的使用十分简单,不需要其他的任何参数.下面继续上一篇文章的例子: SQL> SELECT /*+ NO_NATIVE_FULL_OUTER_JOIN */ T1.ID, T2.ID 2  FROM T1 FULL OUTER JOIN T2 3  ON T1.ID = T2.ID; ID        ID -