查看: 2400|回复: 5

语句优化

[复制链接]
认证徽章
论坛徽章:
9
ITPUB社区OCM联盟徽章
日期:2013-03-27 11:17:11奥运纪念徽章
日期:2013-06-18 09:13:52ITPUB社区千里马徽章
日期:2013-08-22 09:58:03大众
日期:2013-08-30 14:51:33路虎
日期:2013-12-01 18:25:42
发表于 2009-12-17 17:45 | 显示全部楼层 |阅读模式
SQL> explain plan for
  2  SELECT /*+USE_HASH(pf pc cpl) */
  3  *
  4    FROM T_PRODUCT_FEE PF, T_POLICY_CHANGE PC, T_CONTRACT_PRODUCT_LOG CPL
  5   WHERE PF.POLICY_ID = PC.POLICY_ID
  6     AND PC.SERVICE_ID = 213
  7     AND PC.CHANGE_STATUS = '3'
  8     AND PC.CHANGE_ID = CPL.CHANGE_ID
  9     AND PF.PRODUCT_NUM = CPL.PRODUCT_NUM
10     AND PF.PRODUCT_ID = CPL.PRODUCT_ID
11     AND PF.POLICY_ID = CPL.POLICY_ID
12     AND PF.LIST_ID = 30;

已解释。

SQL>  select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------
Plan hash value: 328982415

----------------------------------------------------------------------------------------------------
| Id  | Operation                     | Name                   | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT              |                        |     1 |   784 |  4338   (2)| 00:00:53 |
|*  1 |  HASH JOIN                    |                        |     1 |   784 |  4338   (2)| 00:00:53 |
|*  2 |   HASH JOIN                   |                        |     1 |   351 |     7  (15)| 00:00:01 |
|   3 |    TABLE ACCESS BY INDEX ROWID| T_PRODUCT_FEE          |     1 |   216 |     2   (0)| 00:00:01
|*  4 |     INDEX UNIQUE SCAN         | PK_T_PRODUCT_FEE       |     1 |       |     1   (0)| 00:00:01
|   5 |    TABLE ACCESS BY INDEX ROWID| T_POLICY_CHANGE        |     1 |   135 |     4   (0)| 00:00:0

PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------
|*  6 |     INDEX RANGE SCAN          | TEST123                |     1 |       |     3   (0)| 00:00:01 |
|   7 |   TABLE ACCESS FULL           | T_CONTRACT_PRODUCT_LOG |   286K|   118M|  4329   (2)| 00:00:52 |
----------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - access("PC"."CHANGE_ID"="CPL"."CHANGE_ID" AND "PF"."PRODUCT_NUM"="CPL"."PRODUCT_NUM" AND
              "PF"."PRODUCT_ID"="CPL"."PRODUCT_ID" AND "PF"."POLICY_ID"="CPL"."POLICY_ID")
   2 - access("PF"."POLICY_ID"="PC"."POLICY_ID")
   4 - access("PF"."LIST_ID"=30)

PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------
   6 - access("PC"."SERVICE_ID"=213 AND "PC"."CHANGE_STATUS"='3')

已选择23行。
第7步的索引如何建立才能摆脱TABLE ACCESS FULL?
论坛徽章:
311
行业板块每日发贴之星
日期:2012-07-12 18:47:29双黄蛋
日期:2011-08-12 17:31:04咸鸭蛋
日期:2011-08-18 15:13:51迷宫蛋
日期:2011-08-18 16:58:25紫蛋头
日期:2011-08-31 10:57:28ITPUB十周年纪念徽章
日期:2011-09-27 16:30:47蜘蛛蛋
日期:2011-10-20 15:51:25迷宫蛋
日期:2011-10-29 11:12:59ITPUB十周年纪念徽章
日期:2011-11-01 16:19:41鲜花蛋
日期:2011-11-09 20:33:30
发表于 2009-12-17 17:53 | 显示全部楼层

回复 #1 gaopengtttt 的帖子

你计算一下前两表关联后的结果集,再和CPL关联时,会产生多少条数据?再考虑是否使用索引?

使用道具 举报

回复
认证徽章
论坛徽章:
9
ITPUB社区OCM联盟徽章
日期:2013-03-27 11:17:11奥运纪念徽章
日期:2013-06-18 09:13:52ITPUB社区千里马徽章
日期:2013-08-22 09:58:03大众
日期:2013-08-30 14:51:33路虎
日期:2013-12-01 18:25:42
发表于 2009-12-18 15:14 | 显示全部楼层
你的意思就是说当前面的数据返回的数据在CPL中选择率比较低的话,就可能出现后者全表扫描吧。。

使用道具 举报

回复
论坛徽章:
311
行业板块每日发贴之星
日期:2012-07-12 18:47:29双黄蛋
日期:2011-08-12 17:31:04咸鸭蛋
日期:2011-08-18 15:13:51迷宫蛋
日期:2011-08-18 16:58:25紫蛋头
日期:2011-08-31 10:57:28ITPUB十周年纪念徽章
日期:2011-09-27 16:30:47蜘蛛蛋
日期:2011-10-20 15:51:25迷宫蛋
日期:2011-10-29 11:12:59ITPUB十周年纪念徽章
日期:2011-11-01 16:19:41鲜花蛋
日期:2011-11-09 20:33:30
发表于 2009-12-18 15:20 | 显示全部楼层
原帖由 gaopengtttt 于 2009-12-18 15:14 发表
你的意思就是说当前面的数据返回的数据在CPL中选择率比较低的话,就可能出现后者全表扫描吧。。


刚好相反。前面的数据在CPL中出现/匹配得上的得太多时,用全表扫描比较好;太少了,则可走CPL上的索引。

使用道具 举报

回复
认证徽章
论坛徽章:
9
ITPUB社区OCM联盟徽章
日期:2013-03-27 11:17:11奥运纪念徽章
日期:2013-06-18 09:13:52ITPUB社区千里马徽章
日期:2013-08-22 09:58:03大众
日期:2013-08-30 14:51:33路虎
日期:2013-12-01 18:25:42
发表于 2009-12-18 17:46 | 显示全部楼层
刚好相反。前面的数据在CPL中出现/匹配得上的得太多时,用全表扫描比较好;太少了,则可走CPL上的索引。

我是你这个意思。选择率低表示的是匹配得过多啊。

使用道具 举报

回复
论坛徽章:
28
授权会员
日期:2009-01-04 22:12:21世界杯纪念徽章
日期:2014-07-14 11:31:462014年世界杯参赛球队: 澳大利亚
日期:2014-06-25 11:06:552014年新春福章
日期:2014-02-18 16:42:02ITPUB社区12周年站庆徽章
日期:2013-10-08 14:55:07NBA季后赛纪念徽章
日期:2013-06-21 14:52:05NBA常规赛纪念章
日期:2013-04-22 11:49:35季节之章:冬
日期:2012-11-15 16:55:18ITPUB元老
日期:2011-03-17 09:38:472014年世界杯参赛球队: 俄罗斯
日期:2014-07-17 17:21:42
发表于 2009-12-19 21:36 | 显示全部楼层
analyze table cpl compute statistics for table for all columns;

CHANGE_ID
PRODUCT_NUM
PRODUCT_ID
POLICY_ID

看这几列的数据分布情况,唯一性高可以建个符合索引,看这几个谓词我觉得走hash join是对的,再做个10104 trace看看

说的不对的地方请指正~

使用道具 举报

回复

您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

SACC2019中国系统架构师大会

【数字转型 架构演进】SACC2019中国系统架构师大会,7折限时优惠重磅来袭!
2019年10月31日~11月2日第11届中国系统架构师大会(SACC2019)将在北京隆重召开。四大主线并行的演讲模式,1个主会场、20个技术专场、超千人参与的会议规模,100+来自互联网、金融、制造业、电商等领域的嘉宾阵容,将为广大参会者提供一场最具价值的技术交流盛会。

限时七折期:2019年8月31日前


----------------------------------------

大会官网>>
TOP技术积分榜 社区积分榜 徽章 团队 统计 知识索引树 积分竞拍 文本模式 帮助
  ITPUB首页 | ITPUB论坛 | 数据库技术 | 企业信息化 | 开发技术 | 微软技术 | 软件工程与项目管理 | IBM技术园地 | 行业纵向讨论 | IT招聘 | IT文档
  ChinaUnix | ChinaUnix博客 | ChinaUnix论坛
CopyRight 1999-2011 itpub.net All Right Reserved. 北京盛拓优讯信息技术有限公司版权所有 联系我们 
京ICP备09055130号-4  北京市公安局海淀分局网监中心备案编号:11010802021510 广播电视节目制作经营许可证:编号(京)字第1149号
  
快速回复 返回顶部 返回列表