min ? max ? 执行计划?

create table big_table as select * from dba_objects;
insert into big_table select * from big_table;
insert into big_table select * from big_table;

ALTER TABLE BIG_TABLE MODIFY(OBJECT_ID NULL);

CREATE INDEX I_BT_OBJECT_ID ON BIG_TABLE(OBJECT_ID)

select min(object_id),max(object_id) from big_table;

第1次看到类似的sql语句的时候,感觉会使用索引,并且会走
index full scan (min/max).但是仔细看执行计划发现,发现是使用全表扫描。修改约束OBJECT_ID NOT NULL,仅仅计划变为INDEX FAST FULL SCAN。

修改为
SELECT MIN (object_id), MAX (object_id)
FROM big_table
WHERE object_id IS NOT NULL;

执行计划走INDEX FAST FULL SCAN。

但是单独写SELECT MIN (object_id) FROM big_table;
执行计划就是INDEX FULL SCAN (MIN/MAX)。

如何要执行类似的sql应该将sql语句修改如下:
SELECT a.m1, b.m2
FROM (SELECT MAX (object_id) m1
FROM big_table) a,
(SELECT MIN (object_id) m2
FROM big_table) b

对比如下:
Execution Plan
----------------------------------------------------------
Plan hash value: 2118989048

-----------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-----------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 26 | 6 (0)| 00:00:01 |
| 1 | NESTED LOOPS | | 1 | 26 | 6 (0)| 00:00:01 |
| 2 | VIEW | | 1 | 13 | 3 (0)| 00:00:01 |
| 3 | SORT AGGREGATE | | 1 | 5 | | |
| 4 | INDEX FULL SCAN (MIN/MAX)| I_BT_OBJECT_ID | 405K| 1978K| 3 (0)| 00:00:01 |
| 5 | VIEW | | 1 | 13 | 3 (0)| 00:00:01 |
| 6 | SORT AGGREGATE | | 1 | 5 | | |
| 7 | INDEX FULL SCAN (MIN/MAX)| I_BT_OBJECT_ID | 405K| 1978K| 3 (0)| 00:00:01 |
-----------------------------------------------------------------------------------------------

Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
6 consistent gets
0 physical reads
0 redo size

SELECT MIN (object_id), MAX (object_id)
FROM big_table
WHERE object_id IS NOT NULL;

----------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
----------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 5 | 307 (4)| 00:00:04 |
| 1 | SORT AGGREGATE | | 1 | 5 | | |
| 2 | INDEX FAST FULL SCAN| I_BT_OBJECT_ID | 405K| 1978K| 307 (4)| 00:00:04 |
----------------------------------------------------------------------------------------

Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
1386 consistent gets
0 physical reads
0 redo size

再回到生产系统,一般要执行类似的sql,比如:

select min(a),max(a) from t where xx=:1 ,如果索引建立再xx,a上,如果xx的重复值很多,这样写效率就不高。

时间: 2024-09-25 12:55:45

min ? max ? 执行计划?的相关文章

min ? max ? 执行计划? (续)

链接:http://lfree.itpub.net/post/4950/284166 create table big_table as select * from dba_objects;insert into big_table select * from big_table;insert into big_table select * from big_table; ALTER TABLE BIG_TABLE MODIFY(OBJECT_ID NULL); CREATE INDEX I_B

关键时刻HINT出彩 - PG优化器的参数优化、执行计划固化CASE

背景 有过数据库使用经验的童鞋可曾遇到过SQL执行计划不准确,或者SQL执行计划抖动的问题. PostgreSQL的执行计划与大多数的企业数据库是一样的,都是基于成本优化. 基于成本优化的优化器,在算法靠谱,统计信息准确的前提下,通常得到的执行计划是比较准确的. 那么什么时候执行计划可能不准确呢? 成本估算的算法不好 这个需要内核的不断改进,完善.在没有合理的算法支撑的情况下,内核中往往会带有一些经验值,或者将这些经验值开放给用户设置. 统计信息不准确 PG的统计信息收集调度是几个参数共同决定的

《Oracle高性能SQL引擎剖析:SQL优化与调优机制详解》一2.5 执行计划中其他信息的含义

2.5 执行计划中其他信息的含义 通过DBMS_XPLAN输出执行计划,除了计划本身外,还可以获得一些其他信息帮助我们进一步分析执行计划及语句性能. 2.5.1 查询块和对象别名 在使用DBMS_XPLAN显示执行计划时,选择'ADVANCED'预定义格式作为参数或者加入'ALIAS'控制字符串,可以在输出中看到以下内容: Query Block Name / Object Alias (identified by operation id): -------------------------

执行计划中常见index访问方式(转)

近期有朋友对于单个表上的index各种情况比较模糊,这里对于单个表上,单个index出现的大多数情况进行了总结性测试,给出了测试结果,至于为什么出现这样的试验结果未做过多解释,给读者留下思考的空间.本篇文章仅仅是为了测试hint对index的影响,而不是说明走各种index方式的好坏.参考: INDEX FULL SCAN vs INDEX FAST FULL SCAN创建表模拟测试 SQL> create table t_xifenfei as select object_id,object_

《Oracle高性能SQL引擎剖析:SQL优化与调优机制详解》一2.4 执行计划各个操作的含义

2.4 执行计划各个操作的含义 通常我们所说的执行计划操作包含两个部分:操作与其选项.例如,哈希关联反关联(HASH JOIN ANTI)中,哈希关联(HASH JOIN)是一种操作,"反"关联(ANTI)则是其选项:该操作还可以与其他选项(如"半"关联,SEMI)配合形成不同的执行计划操作. 执行计划中的操作数量非常多.我们下面列出的操作是Oracle 10gR2中的绝大多数操作.Oracle的每个版本都会有一些新的特性出现,而其中一些新特性又会带来新的操作,或者

批量删除数据后, 未释放empty索引页导致mergejoin执行计划变慢 case - 分析与规避方法

标签 PostgreSQL , merge join , min , max , 优化器 , 索引倾斜 , 垃圾回收 背景 PostgreSQL支持三种JOIN的方法,nestloop, merge, hash. 这三种JOIN方法的差别和原理可以参考 https://www.postgresql.org/docs/devel/static/planner-optimizer.html <PostgreSQL nestloop/hash/merge join讲解> nested loop jo

FAQ系列 | EXPLAIN执行计划中要重点关注哪些要素

导读 EXPLAIN的结果中,有哪些关键信息值得注意呢? MySQL的EXPLAIN当然和ORACLE的没法比,不过我们从它输出的结果中,也可以得到很多有用的信息. 总的来说,我们只需要关注结果中的几列: 列名 备注 type 本次查询表联接类型,从这里可以看到本次查询大概的效率 key 最终选择的索引,如果没有索引的话,本次查询效率通常很差 key_len 本次查询用于结果过滤的索引实际长度,参见另一篇分享(FAQ系列-解读EXPLAIN执行计划中的key_len) rows 预计需要扫描的记

MongoDB执行计划获取(db.collection.explain())

在RDBMS中,无论那种数据库,都提供了SQL剖析工具,用来解决SQL效率低下的问题.在MongoDB中,也有相应的策略来实现剖析.MongoDB提供了db.collection.explain()方法, cursor.explain()方法,和explain命令去返回查询计划信息和查询计划的执行统计信息.这为我们诊断查询提供了极大的便利,本文主要描述db.collection.explain()的相关用法. 一.db.collection.explain()简介 支持下列操作返回查询计划 ag

MSSQLSERVER执行计划详解

原文:MSSQLSERVER执行计划详解 序言 本篇主要目的有二: 1.看懂t-sql的执行计划,明白执行计划中的一些常识. 2.能够分析执行计划,找到优化sql性能的思路或方案. 如果你对sql查询优化的理解或常识不是很深入,那么推荐几骗博文给你:SqlServer性能检测和优化工具使用详细 ,sql语句的优化分析,T-sql语句查询执行顺序. 执行计划简介 1.什么是执行计划? 大哥提交的sql语句,数据库查询优化器,经过分析生成多个数据库可以识别的高效执行查询方式.然后优化器会在众多执行计