当执行计划中出现BITMAP CONVERSION TO ROWIDS关键字时，需要注意了。
前言
前些天优化了一些耗费buffers较多的SQL，但系统CPU降低的效果不明显，于是又拉了awr报告，查看了SQL ordered by Gets排名前列的SQL。
分析
SQL代码：
select distinct pro5.value as CUSTOMERCODE,
to_date('19000101000000', 'yyyymmddhh24miss') as LAST_UPDATE_TIME,
pro2.value as NAME,
nvl(pro3.value, '$$400006000004') as GENDER,
decode(pro4.value,
'$$400003000001',
decode(length(trim(pro5.value)),
18,
substr(trim(pro5.value), 7, 8)),
null) as BIRTHDAY,
decode(pro4.value, '$$400003000001', pro5.value, null) as CERT_NO,
pro4.value as CERTIFICATE_TYPE,
pro5.value as CERTIFICATE_NO,
null as NATION,
null as EFFECTIVE_DATE,
null as EXPIRE_DATE
from policy p
inner join role r
on p.topactualid = r.topactualid
and r.kind = 'INSURANCECERTIFICATELIST'
inner join property pro2
on r.topactualid = pro2.topactualid
and r.actualid = pro2.parentactualid
and r.parentagreementid = pro2.parentagreementid
and r.topagreementid = pro2.topagreementid
and pro2.kind = 'CUSTOMERNAME'
inner join property pro3
on r.topactualid = pro3.topactualid
and r.actualid = pro3.parentactualid
and r.parentagreementid = pro3.parentagreementid
and r.topagreementid = pro3.topagreementid
and pro3.kind = 'PERSONSEX'
inner join property pro4
on r.topactualid = pro4.topactualid
and r.actualid = pro4.parentactualid
and r.parentagreementid = pro4.parentagreementid
and r.topagreementid = pro4.topagreementid
and pro4.kind = 'CERTIFICATETYPE'
inner join property pro5
on r.topactualid = pro5.topactualid
and r.actualid = pro5.parentactualid
and r.parentagreementid = pro5.parentagreementid
and r.topagreementid = pro5.topagreementid
and pro5.kind = 'CERTIFICATECODE' and pro5.value is not null
left join endorsement e
on p.endorsementid = e.endorsementid
where p.productcode = '00070002'
and p.currentflag = 'Y'
and (p.uniquecode like '013100%' or p.uniquecode like '011000%')
and ((p.policystatus = '$$900001103001') or
(e.endorsementstatus = '$$900002106001' and
e.ISSUEDATE > to_date('20160411', 'YYYYMMDD')))
执行计划：
Plan hash value: 3936231819
------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 336 | 124K (1)| 00:24:55 |
| 1 | HASH UNIQUE | | 1 | 336 | 124K (1)| 00:24:55 |
| 2 | NESTED LOOPS | | 1 | 336 | 124K (1)| 00:24:55 |
| 3 | NESTED LOOPS | | 1 | 284 | 124K (1)| 00:24:55 |
| 4 | NESTED LOOPS | | 1 | 232 | 124K (1)| 00:24:55 |
| 5 | NESTED LOOPS | | 51 | 9180 | 124K (1)| 00:24:50 |
| 6 | NESTED LOOPS | | 14950 | 1868K| 11388 (1)| 00:02:17 |
|* 7 | FILTER | | | | | |
| 8 | NESTED LOOPS OUTER | | 701 | 58183 | 6559 (1)| 00:01:19 |
|* 9 | TABLE ACCESS FULL | POLICY | 2661 | 129K| 5834 (1)| 00:01:11 |
| 10 | TABLE ACCESS BY INDEX ROWID | ENDORSEMENT | 1 | 33 | 1 (0)| 00:00:01 |
|* 11 | INDEX UNIQUE SCAN | ENDORSEMENT_PK | 1 | | 0 (0)| 00:00:01 |
|* 12 | TABLE ACCESS BY INDEX ROWID | ROLE | 21 | 945 | 25 (0)| 00:00:01 |
|* 13 | INDEX RANGE SCAN | TC_ROLE66 | 453 | | 4 (0)| 00:00:01 |
|* 14 | TABLE ACCESS BY INDEX ROWID | PROPERTY | 1 | 52 | 124K (1)| 00:24:50 |
| 15 | BITMAP CONVERSION TO ROWIDS | | | | | |
| 16 | BITMAP AND | | | | | |
| 17 | BITMAP CONVERSION FROM ROWIDS| | | | | |
|* 18 | INDEX RANGE SCAN | TC_PROPERTY_PARENT | 12 | | 3 (0)| 00:00:01 |
| 19 | BITMAP CONVERSION FROM ROWIDS| | | | | |
|* 20 | INDEX RANGE SCAN | TC_PROPERTY24 | 12 | | 3 (0)| 00:00:01 |
|* 21 | TABLE ACCESS BY INDEX ROWID | PROPERTY | 1 | 52 | 13 (0)| 00:00:01 |
|* 22 | INDEX RANGE SCAN | TC_PROPERTY_PARENT | 12 | | 3 (0)| 00:00:01 |
|* 23 | TABLE ACCESS BY INDEX ROWID | PROPERTY | 1 | 52 | 3 (0)| 00:00:01 |
|* 24 | INDEX RANGE SCAN | TC_PROPERTY_PARENT | 12 | | 3 (0)| 00:00:01 |
|* 25 | TABLE ACCESS BY INDEX ROWID | PROPERTY | 1 | 52 | 3 (0)| 00:00:01 |
|* 26 | INDEX RANGE SCAN | TC_PROPERTY_PARENT | 12 | | 3 (0)| 00:00:01 |
------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
7 - filter("P"."POLICYSTATUS"='$$900001103001' OR "E"."ENDORSEMENTSTATUS"='$$900002106001' AND
"E"."ISSUEDATE">TIMESTAMP' 2016-04-11 00:00:00')
9 - filter("P"."PRODUCTCODE"='00070002' AND ("P"."UNIQUECODE" LIKE '013100%' OR "P"."UNIQUECODE"
LIKE '011000%') AND "P"."CURRENTFLAG"='Y')
11 - access("P"."ENDORSEMENTID"="E"."ENDORSEMENTID"(+))
12 - filter("R"."KIND"='INSURANCECERTIFICATELIST')
13 - access("P"."TOPACTUALID"="R"."TOPACTUALID")
14 - filter("PRO5"."VALUE" IS NOT NULL AND "PRO5"."KIND"='CERTIFICATECODE' AND
"R"."PARENTAGREEMENTID"="PRO5"."PARENTAGREEMENTID" AND "R"."TOPAGREEMENTID"="PRO5"."TOPAGREEMENTID")
18 - access("R"."ACTUALID"="PRO5"."PARENTACTUALID")
20 - access("R"."TOPACTUALID"="PRO5"."TOPACTUALID")
21 - filter("PRO2"."KIND"='CUSTOMERNAME' AND "R"."TOPACTUALID"="PRO2"."TOPACTUALID" AND
"R"."PARENTAGREEMENTID"="PRO2"."PARENTAGREEMENTID" AND "R"."TOPAGREEMENTID"="PRO2"."TOPAGREEMENTID")
22 - access("R"."ACTUALID"="PRO2"."PARENTACTUALID")
23 - filter("PRO4"."KIND"='CERTIFICATETYPE' AND "R"."TOPACTUALID"="PRO4"."TOPACTUALID" AND
"R"."PARENTAGREEMENTID"="PRO4"."PARENTAGREEMENTID" AND "R"."TOPAGREEMENTID"="PRO4"."TOPAGREEMENTID")
24 - access("R"."ACTUALID"="PRO4"."PARENTACTUALID")
25 - filter("PRO3"."KIND"='PERSONSEX' AND "R"."TOPACTUALID"="PRO3"."TOPACTUALID" AND
"R"."PARENTAGREEMENTID"="PRO3"."PARENTAGREEMENTID" AND "R"."TOPAGREEMENTID"="PRO3"."TOPAGREEMENTID")
26 - access("R"."ACTUALID"="PRO3"."PARENTACTUALID")
分析：
1）执行计划中 id = 15 关键字为BITMAP CONVERSION TO ROWIDS，此关键字在此之前都未遇见过，于是谷歌下，有了以下解释：
1)出现这样的情况，是因为表中存在不适当的索引，这些索引列的唯一度不高，oracle就有可能选择两个这样的索引转为bitmap来执行
2)根据这两个索引的值再确认共同有的ROWID，最后再通过ROWID回表提取符合条件的数据。
2) 可以使用/*+ opt_param('_b_tree_bitmap_plans','false') */hint 在sql级消除bitmap
3） 也可以删除选择率低的索引，建立复合索引进行改善
4） 根据执行计划的谓词信息，我建立了如下索引：
create index IDX_POLICY_01 on POLICY (PRODUCTCODE, CURRENTFLAG, UNIQUECODE);
create index IDX_PROPERTY_TEST02 on PROPERTY (KIND, PARENTACTUALID, TOPACTUALID, PARENTAGREEMENTID, TOPAGREEMENTID, VALUE) nologging;5）建立索引后的执行计划：
Plan hash value: 2001935116
-----------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-----------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 336 | 10938 (1)| 00:02:12 |
| 1 | HASH UNIQUE | | 1 | 336 | 10938 (1)| 00:02:12 |
| 2 | NESTED LOOPS | | 1 | 336 | 10937 (1)| 00:02:12 |
| 3 | NESTED LOOPS | | 1 | 284 | 10934 (1)| 00:02:12 |
| 4 | NESTED LOOPS | | 1 | 232 | 10931 (1)| 00:02:12 |
| 5 | NESTED LOOPS | | 1 | 180 | 10928 (1)| 00:02:12 |
| 6 | NESTED LOOPS | | 875 | 109K| 8301 (1)| 00:01:40 |
|* 7 | FILTER | | | | | |
| 8 | NESTED LOOPS OUTER | | 300 | 24900 | 6500 (1)| 00:01:19 |
|* 9 | TABLE ACCESS FULL | POLICY | 2776 | 135K| 5751 (1)| 00:01:10 |
| 10 | TABLE ACCESS BY INDEX ROWID| ENDORSEMENT | 1 | 33 | 1 (0)| 00:00:01 |
|* 11 | INDEX UNIQUE SCAN | ENDORSEMENT_PK | 1 | | 0 (0)| 00:00:01 |
|* 12 | TABLE ACCESS BY INDEX ROWID | ROLE | 3 | 135 | 6 (0)| 00:00:01 |
|* 13 | INDEX RANGE SCAN | TC_ROLE66 | 62 | | 3 (0)| 00:00:01 |
|* 14 | INDEX RANGE SCAN | IDX_PROPERTY_TEST02 | 1 | 52 | 3 (0)| 00:00:01 |
|* 15 | INDEX RANGE SCAN | IDX_PROPERTY_TEST02 | 1 | 52 | 3 (0)| 00:00:01 |
|* 16 | INDEX RANGE SCAN | IDX_PROPERTY_TEST02 | 1 | 52 | 3 (0)| 00:00:01 |
|* 17 | INDEX RANGE SCAN | IDX_PROPERTY_TEST02 | 1 | 52 | 3 (0)| 00:00:01 |
-----------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
7 - filter("P"."POLICYSTATUS"='$$900001103001' OR "E"."ENDORSEMENTSTATUS"='$$900002106001' AND
"E"."ISSUEDATE">TIMESTAMP' 2016-04-11 00:00:00')
9 - filter("P"."PRODUCTCODE"='00070002' AND ("P"."UNIQUECODE" LIKE '013100%' OR
"P"."UNIQUECODE" LIKE '011000%') AND "P"."CURRENTFLAG"='Y')
11 - access("P"."ENDORSEMENTID"="E"."ENDORSEMENTID"(+))
12 - filter("R"."KIND"='INSURANCECERTIFICATELIST')
13 - access("P"."TOPACTUALID"="R"."TOPACTUALID")
14 - access("R"."ACTUALID"="PRO4"."PARENTACTUALID" AND "R"."TOPACTUALID"="PRO4"."TOPACTUALID"
AND "R"."PARENTAGREEMENTID"="PRO4"."PARENTAGREEMENTID" AND
"R"."TOPAGREEMENTID"="PRO4"."TOPAGREEMENTID" AND "PRO4"."KIND"='CERTIFICATETYPE')
15 - access("R"."ACTUALID"="PRO3"."PARENTACTUALID" AND "R"."TOPACTUALID"="PRO3"."TOPACTUALID"
AND "R"."PARENTAGREEMENTID"="PRO3"."PARENTAGREEMENTID" AND
"R"."TOPAGREEMENTID"="PRO3"."TOPAGREEMENTID" AND "PRO3"."KIND"='PERSONSEX')
16 - access("R"."ACTUALID"="PRO2"."PARENTACTUALID" AND "R"."TOPACTUALID"="PRO2"."TOPACTUALID"
AND "R"."PARENTAGREEMENTID"="PRO2"."PARENTAGREEMENTID" AND
"R"."TOPAGREEMENTID"="PRO2"."TOPAGREEMENTID" AND "PRO2"."KIND"='CUSTOMERNAME')
17 - access("R"."ACTUALID"="PRO5"."PARENTACTUALID" AND "R"."TOPACTUALID"="PRO5"."TOPACTUALID"
AND "R"."PARENTAGREEMENTID"="PRO5"."PARENTAGREEMENTID" AND
"R"."TOPAGREEMENTID"="PRO5"."TOPAGREEMENTID" AND "PRO5"."KIND"='CERTIFICATECODE')
filter("PRO5"."VALUE" IS NOT NULL)
优化后
建立索引后，sql从原来的450s降低到20s，buffers 消耗也显著降低。
当执行计划中出现BITMAP CONVERSION TO ROWIDS关键字时，需要注意了。的更多相关文章
- SQL Server 2000中的并行处理和执行计划中的位图运算符
SQL Server 2000中的并行处理和执行计划中的位图运算符 摘抄自:SQLServer 2000并行处理和位图简介 刘志斌 并行查询介绍Degree of Parallelism(并行度) 一 ...
- 浅析SQL SERVER执行计划中的各类怪相
在查看执行计划或调优过程中,执行计划里面有些现象总会让人有些疑惑不解: 1:为什么同一条SQL语句有时候会走索引查找,有时候SQL脚本又不走索引查找,反而走全表扫描? 2:同一条SQL语句,查询条件的 ...
- [转载] EXPLAIN执行计划中要重点关注哪些要素
原文: https://mp.weixin.qq.com/s?__biz=MjM5NzAzMTY4NQ==&mid=400738936&idx=1&sn=2910b4119b9 ...
- SQL Server 执行计划中的扫描方式举例说明
SQL Server 执行计划中的扫描方式举例说明 原文地址:http://www.cnblogs.com/zihunqingxin/p/3201155.html 1.执行计划使用方式 选中需要执行的 ...
- 执行计划中常见index访问方式(转)
近期有朋友对于单个表上的index各种情况比较模糊,这里对于单个表上,单个index出现的大多数情况进行了总结性测试,给出了测试结果,至于为什么出现这样的试验结果未做过多解释,给读者留下思考的空间.本 ...
- MySQL 执行计划中Extra(Using where,Using index,Using index condition,Using index,Using where)的浅析
关于如何理解MySQL执行计划中Extra列的Using where.Using Index.Using index condition,Using index,Using where这四者的区别 ...
- 解读EXPLAIN执行计划中的key_len（转）
原文:http://imysql.com/2015/10/20/mysql-faq-key-len-in-explain.shtml 导读 EXPLAIN中的key_len一列表示什么意思,该如何解读 ...
- EXPLAIN执行计划中要重点关注哪些要素（叶金荣）
原文:http://mp.weixin.qq.com/s/CDKN_nPcIjzA_U5-xwAE5w 导读 EXPLAIN的结果中,有哪些关键信息值得注意呢? MySQL的EXPLAIN当然和ORA ...
- EXPLAIN执行计划中要重点关注哪些要素
MySQL的EXPLAIN当然和ORACLE的没法比,不过我们从它输出的结果中,也可以得到很多有用的信息. 总的来说,我们只需要关注结果中的几列: 列名 备注 type 本次查询表联接类型,从这里可以 ...
随机推荐
- UVa 12712 && UVaLive 6653 Pattern Locker (排列组合)
题意:给定 一个n * n 的宫格,就是图案解锁,然后问你在区间 [l, r] 内的所有的个数进行组合,有多少种. 析:本来以为是数位DP,后来仔细一想是排列组合,因为怎么组合都行,不用考虑实际要考虑 ...
- bzoj 1230: [Usaco2008 Nov]lites 开关灯【线段树】
在线段树上记录长度.区间01翻转标记.当前1个数.传递tag的时候用长度-1个数即可 #include<iostream> #include<cstdio> using nam ...
- 【NOIP2006】作业调度方案 {语文难题}
Description: 我们现在要利用 m 台机器加工 n 个工件,每个工件都有 m 道工序,每道工序都在不同的指定的机器上完成.每个工件的每道工序都有指定的加工时间. 每个工件的每个工序称为一个 ...
- Luogu P1073 最优贸易【最短路/建反图】 By cellur925
题目传送门 这么经典的题目,还是看了lyd的题解....唉难过. 一句话题意:在一张点有全都的图上找一条从1到n的路径,存在两个点p,q(p<q),使val[q]-val[p]最大. 给出的图是 ...
- 【SpringCloud构建微服务系列】微服务网关Zuul
一.为什么要用微服务网关 在微服务架构中,一般不同的微服务有不同的网络地址,而外部客户端(如手机APP)可能需要调用多个接口才能完成一次业务需求.例如一个电影购票的手机APP,可能会调用多个微服务的接 ...
- 进击的Python【第十一章】：消息队列介绍、RabbitMQ&Redis的重点介绍与简单应用
消息队列介绍.RabbitMQ.Redis 一.什么是消息队列 这个概念我们百度Google能查到一大堆文章,所以我就通俗的讲下消息队列的基本思路. 还记得原来写过Queue的文章,不管是线程queu ...
- [POI2007]四进制的天平Wag
Description Mary准备举办一个聚会,她准备邀请很多的人参加她的聚会.并且她准备给每位来宾准备一些金子作为礼物.为了不伤及每个人的脸面,每个人获得的金子必须相同.Mary将要用一个天平来称 ...
- Redis相关问题收集
问题一.强制关闭Redis快照导致不能持久化 MISCONF Redis is configured to save RDB snapshots, but is currently not able ...
- Node.js搭建静态服务器
let http = require('http'); let url = require('url'); let fs = require('fs'); let path = require('pa ...
- Spark学习笔记--Spark在Windows下的环境搭建（转）
本文主要是讲解Spark在Windows环境是如何搭建的 一.JDK的安装 1.1 下载JDK 首先需要安装JDK,并且将环境变量配置好,如果已经安装了的老司机可以忽略.JDK(全称是JavaTM P ...