查看: 2468|回复: 6

请帮忙优化一个语句

[复制链接]
论坛徽章:
15
数据库板块每日发贴之星
日期:2008-06-30 01:01:54奥运会纪念徽章:羽毛球
日期:2012-06-26 15:21:24ITPUB十周年纪念徽章
日期:2011-11-01 16:23:26数据库板块每日发贴之星
日期:2011-07-15 01:01:01ITPUB9周年纪念徽章
日期:2010-10-08 09:28:512010年世界杯参赛球队:加纳
日期:2010-07-27 08:59:132010年世界杯参赛球队:智利
日期:2010-07-14 16:06:302010年世界杯参赛球队:斯洛伐克
日期:2010-07-10 02:35:492010年世界杯参赛球队:英格兰
日期:2010-07-09 18:54:212010年世界杯参赛球队:瑞士
日期:2010-01-22 13:33:24
发表于 2010-3-26 16:20 | 显示全部楼层 |阅读模式
pub_messageinfo--163万
sm_user--1204


'PUB_MESSAGEINFO' 有3个索引
1        PK_PUB_MESSAGEINFO        PK_MESSAGEINFO
2        IDX$$_13670001        CHECKMAN
3        I1_MESSAGEINFO        SENDERMAN
4        I1_MESSAGEINFO        TYPE


'SM_USER' 有两个索引
1        I_SM_USER        USER_CODE
2        I_SM_USER        PK_CORP
3        PK_SM_USER        CUSERID




  
  select a.pk_messageinfo, a.senderman, b.user_name, a.checkman, a.pk_corp, a.type, a.state, a.url, a.title, a.content, a.senddate,
   a.priority, a.dealdate, a.billid, a.billno, a.pk_billtype, a.pk_srcbilltype, a.pk_busitype, a.actiontype, a.titlecolor
   from pub_messageinfo a, sm_user b where a.senderman = b.cuserid ( + ) and ( ( ( checkman = '0001A810000000003Z34' and a.type = 1 )
   or ( a.type = - 1 and a.state <> 2 and ( a.pk_corp = '1129' or a.pk_corp = '0001' ) ) )
   and ( a.receivedeleteflag is null or a.receivedeleteflag = 'N' ) and a.state = 0 )
   order by senddate desc
  





Execution Plan
----------------------------------------------------------
Plan hash value: 3134901396

--------------------------------------------------------------------------------------------------
| Id  | Operation                      | Name            | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT               |                 |   161 | 51842 | 13296   (1)| 00:02:40 |
|   1 |  SORT ORDER BY                 |                 |   161 | 51842 | 13296   (1)| 00:02:40 |
|   2 |   CONCATENATION                |                 |       |       |            |          |
|   3 |    NESTED LOOPS OUTER          |                 |     1 |   322 | 13238   (1)| 00:02:39 |
|*  4 |     TABLE ACCESS BY INDEX ROWID| PUB_MESSAGEINFO |     1 |   294 | 13237   (1)| 00:02:39 |
|*  5 |      INDEX SKIP SCAN           | I1_MESSAGEINFO  |     1 |       | 13236   (1)| 00:02:39 |
|   6 |     TABLE ACCESS BY INDEX ROWID| SM_USER         |     1 |    28 |     1   (0)| 00:00:01 |
|*  7 |      INDEX UNIQUE SCAN         | PK_SM_USER      |     1 |       |     0   (0)| 00:00:01 |
|*  8 |    HASH JOIN OUTER             |                 |   160 | 51520 |    58   (2)| 00:00:01 |
|*  9 |     TABLE ACCESS BY INDEX ROWID| PUB_MESSAGEINFO |   160 | 47040 |    49   (0)| 00:00:01 |
|* 10 |      INDEX RANGE SCAN          | IDX$$_13670001  |   172 |       |     3   (0)| 00:00:01 |
|  11 |     TABLE ACCESS FULL          | SM_USER         |  1212 | 33936 |     8   (0)| 00:00:01 |
--------------------------------------------------------------------------------------------------

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

   4 - filter(("A"."PK_CORP"='0001' OR "A"."PK_CORP"='1129') AND ("A"."RECEIVEDELETEFLAG"
              IS NULL OR "A"."RECEIVEDELETEFLAG"='N') AND "A"."STATE"=0 AND "A"."STATE"<>2)
   5 - access("A"."TYPE"=(-1))
       filter("A"."TYPE"=(-1))
   7 - access("A"."SENDERMAN"="B"."CUSERID"(+))
   8 - access("A"."SENDERMAN"="B"."CUSERID"(+))
   9 - filter(("A"."RECEIVEDELETEFLAG" IS NULL OR "A"."RECEIVEDELETEFLAG"='N') AND
              "A"."STATE"=0 AND "A"."TYPE"=1 AND (LNNVL("A"."TYPE"=(-1)) OR LNNVL("A"."PK_CORP"='0001')
              AND LNNVL("A"."PK_CORP"='1129') OR LNNVL("A"."STATE"<>2)))
  10 - access("CHECKMAN"='0001A810000000003Z34')


Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
         92  consistent gets
          0  physical reads
          0  redo size
       1272  bytes sent via SQL*Net to client
        327  bytes received via SQL*Net from client
          1  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
          0  rows processed
认证徽章
论坛徽章:
131
2006年度最佳技术回答
日期:2007-01-24 12:58:48福特
日期:2013-10-24 13:57:422014年新春福章
日期:2014-02-18 16:41:11马上有车
日期:2014-02-18 16:41:11马上有车
日期:2014-02-19 11:55:14马上有房
日期:2014-02-19 11:55:14马上有钱
日期:2014-02-19 11:55:14马上有对象
日期:2014-02-19 11:55:14马上加薪
日期:2014-02-19 11:55:142013年新春福章
日期:2013-02-25 14:51:24
发表于 2010-3-26 16:51 | 显示全部楼层
92  consistent gets

这还需要tune吗?

使用道具 举报

回复
论坛徽章:
15
数据库板块每日发贴之星
日期:2008-06-30 01:01:54奥运会纪念徽章:羽毛球
日期:2012-06-26 15:21:24ITPUB十周年纪念徽章
日期:2011-11-01 16:23:26数据库板块每日发贴之星
日期:2011-07-15 01:01:01ITPUB9周年纪念徽章
日期:2010-10-08 09:28:512010年世界杯参赛球队:加纳
日期:2010-07-27 08:59:132010年世界杯参赛球队:智利
日期:2010-07-14 16:06:302010年世界杯参赛球队:斯洛伐克
日期:2010-07-10 02:35:492010年世界杯参赛球队:英格兰
日期:2010-07-09 18:54:212010年世界杯参赛球队:瑞士
日期:2010-01-22 13:33:24
 楼主| 发表于 2010-3-29 14:29 | 显示全部楼层
原帖由 rollingpig 于 2010-3-26 16:51 发表
92  consistent gets

这还需要tune吗?

s.jpg






在awr报告里面,这个语句排名第一。

每次 gets是74,838.33,

但是我把这个语句单独拿出来跑,就是上面的92个。

使用道具 举报

回复
论坛徽章:
136
ITPUB年度最佳技术回答奖
日期:2010-06-12 13:17:14现代
日期:2013-10-02 14:53:59路虎
日期:2013-11-22 12:26:182014年新春福章
日期:2014-02-18 16:42:02马上有房
日期:2014-02-18 16:42:02马上有车
日期:2014-02-19 11:55:14马上有房
日期:2014-02-19 11:55:14马上有钱
日期:2014-02-19 11:55:14马上有对象
日期:2014-02-19 11:55:14马上加薪
日期:2014-02-19 11:55:14
发表于 2010-3-29 14:33 | 显示全部楼层
可能是awr里面的执行计划有问题,那个表的历史数据应该是可以干掉的

使用道具 举报

回复
论坛徽章:
1
复活蛋
日期:2012-03-20 18:41:28
发表于 2010-3-29 14:39 | 显示全部楼层
没记错的话,pub_messageinfo表记录的是登陆首页的一些提示信息,基本上没有用。如果数量很多会越来越慢。
可以把最近之前的记录delete掉,就不会有问题了。当然你也可以帮TA把记录阅读了:update set receivedeleteflag = 'Y'



原帖由 hdydmichael 于 2010-3-26 16:20 发表
pub_messageinfo--163万
sm_user--1204


'PUB_MESSAGEINFO' 有3个索引
1        PK_PUB_MESSAGEINFO        PK_MESSAGEINFO
2        IDX$$_13670001        CHECKMAN
3        I1_MESSAGEINFO        SENDERMAN
4        I1_MESSAGEINFO        TYPE


'SM_USER' 有两个索引
1        I_SM_USER        USER_CODE
2        I_SM_USER        PK_CORP
3        PK_SM_USER        CUSERID




  
  select a.pk_messageinfo, a.senderman, b.user_name, a.checkman, a.pk_corp, a.type, a.state, a.url, a.title, a.content, a.senddate,
   a.priority, a.dealdate, a.billid, a.billno, a.pk_billtype, a.pk_srcbilltype, a.pk_busitype, a.actiontype, a.titlecolor
   from pub_messageinfo a, sm_user b where a.senderman = b.cuserid ( + ) and ( ( ( checkman = '0001A810000000003Z34' and a.type = 1 )
   or ( a.type = - 1 and a.state  2 and ( a.pk_corp = '1129' or a.pk_corp = '0001' ) ) )
   and ( a.receivedeleteflag is null or a.receivedeleteflag = 'N' ) and a.state = 0 )
   order by senddate desc
  





Execution Plan
----------------------------------------------------------
Plan hash value: 3134901396

--------------------------------------------------------------------------------------------------
| Id  | Operation                      | Name            | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT               |                 |   161 | 51842 | 13296   (1)| 00:02:40 |
|   1 |  SORT ORDER BY                 |                 |   161 | 51842 | 13296   (1)| 00:02:40 |
|   2 |   CONCATENATION                |                 |       |       |            |          |
|   3 |    NESTED LOOPS OUTER          |                 |     1 |   322 | 13238   (1)| 00:02:39 |
|*  4 |     TABLE ACCESS BY INDEX ROWID| PUB_MESSAGEINFO |     1 |   294 | 13237   (1)| 00:02:39 |
|*  5 |      INDEX SKIP SCAN           | I1_MESSAGEINFO  |     1 |       | 13236   (1)| 00:02:39 |
|   6 |     TABLE ACCESS BY INDEX ROWID| SM_USER         |     1 |    28 |     1   (0)| 00:00:01 |
|*  7 |      INDEX UNIQUE SCAN         | PK_SM_USER      |     1 |       |     0   (0)| 00:00:01 |
|*  8 |    HASH JOIN OUTER             |                 |   160 | 51520 |    58   (2)| 00:00:01 |
|*  9 |     TABLE ACCESS BY INDEX ROWID| PUB_MESSAGEINFO |   160 | 47040 |    49   (0)| 00:00:01 |
|* 10 |      INDEX RANGE SCAN          | IDX$$_13670001  |   172 |       |     3   (0)| 00:00:01 |
|  11 |     TABLE ACCESS FULL          | SM_USER         |  1212 | 33936 |     8   (0)| 00:00:01 |
--------------------------------------------------------------------------------------------------

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

   4 - filter(("A"."PK_CORP"='0001' OR "A"."PK_CORP"='1129') AND ("A"."RECEIVEDELETEFLAG"
              IS NULL OR "A"."RECEIVEDELETEFLAG"='N') AND "A"."STATE"=0 AND "A"."STATE"2)
   5 - access("A"."TYPE"=(-1))
       filter("A"."TYPE"=(-1))
   7 - access("A"."SENDERMAN"="B"."CUSERID"(+))
   8 - access("A"."SENDERMAN"="B"."CUSERID"(+))
   9 - filter(("A"."RECEIVEDELETEFLAG" IS NULL OR "A"."RECEIVEDELETEFLAG"='N') AND
              "A"."STATE"=0 AND "A"."TYPE"=1 AND (LNNVL("A"."TYPE"=(-1)) OR LNNVL("A"."PK_CORP"='0001')
              AND LNNVL("A"."PK_CORP"='1129') OR LNNVL("A"."STATE"2)))
  10 - access("CHECKMAN"='0001A810000000003Z34')


Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
         92  consistent gets
          0  physical reads
          0  redo size
       1272  bytes sent via SQL*Net to client
        327  bytes received via SQL*Net from client
          1  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
          0  rows processed

使用道具 举报

回复
论坛徽章:
19
2010年世界杯参赛球队:韩国
日期:2009-12-20 20:11:33沸羊羊
日期:2015-03-26 14:41:40暖羊羊
日期:2015-06-15 10:03:48天枰座
日期:2015-07-18 17:23:54托尼托尼·乔巴
日期:2017-01-25 09:38:19秀才
日期:2017-03-02 10:30:14秀才
日期:2017-03-02 10:30:35秀才
日期:2017-06-29 10:16:48技术图书徽章
日期:2017-07-11 09:10:262015年新春福章
日期:2015-03-06 11:57:31
发表于 2010-3-29 14:50 | 显示全部楼层
a.type = - 1 这个实际有多少行? type会不断被修改吗?

使用道具 举报

回复
论坛徽章:
26
授权会员
日期:2006-04-11 16:11:08会员2006贡献徽章
日期:2006-04-17 13:46:34萤石
日期:2013-12-12 12:56:09劳斯莱斯
日期:2013-12-10 23:07:17法拉利
日期:2013-09-10 06:09:20宝马
日期:2013-09-10 06:09:402011新春纪念徽章
日期:2011-01-04 10:37:342011新春纪念徽章
日期:2011-02-18 11:42:472012新春纪念徽章
日期:2012-01-04 11:49:542013年新春福章
日期:2013-02-25 14:51:24
发表于 2010-3-29 15:29 | 显示全部楼层
这个sql语句,单次执行花费2:40。
但是其中有2:39是用在那个index skip scan上边了。。


|*  5 |      INDEX SKIP SCAN           | I1_MESSAGEINFO  |     1 |       | 13236   (1)| 00:02:39 |


虽然,不了解你的数据分布状况。 但是index skip scan一定不是一种最优的选择。。 如果有index 可以避免这个index skip scan, 而是让他走index range scan, 效率肯定会提高。。

使用道具 举报

回复

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

本版积分规则 发表回复

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