楼主: anlinew

[精华] 几个SQL写法影响执行效率的案例

[复制链接]
论坛徽章:
4
2010新春纪念徽章
日期:2010-01-04 08:33:082010新春纪念徽章
日期:2010-03-01 11:19:07参与SAP云计算之旅活动纪念
日期:2011-05-17 13:35:45ITPUB十周年纪念徽章
日期:2011-11-01 16:21:15
21#
发表于 2010-8-19 00:02 | 只看该作者
MARK 学习!太棒了!

使用道具 举报

回复
招聘 : 数据库管理员
论坛徽章:
20
祖国60周年纪念徽章
日期:2009-10-09 08:28:00数据库板块每日发贴之星
日期:2011-02-20 01:01:01ITPUB季度 技术新星
日期:2011-04-02 10:31:09ITPUB十周年纪念徽章
日期:2011-11-01 16:24:042012新春纪念徽章
日期:2012-01-04 11:54:26玉石琵琶
日期:2012-02-21 15:04:38最佳人气徽章
日期:2012-03-13 17:39:18ITPUB 11周年纪念徽章
日期:2012-10-09 18:09:192013年新春福章
日期:2013-02-25 14:51:242011新春纪念徽章
日期:2011-02-18 11:43:33
22#
发表于 2010-8-19 09:11 | 只看该作者
good。。。。。

使用道具 举报

回复
23#
发表于 2010-8-19 09:33 | 只看该作者
路过学习

使用道具 举报

回复
论坛徽章:
2
生肖徽章:虎
日期:2006-09-07 10:19:36数据库板块每日发贴之星
日期:2010-03-21 01:01:04
24#
发表于 2010-8-19 11:42 | 只看该作者
这个贴没顶?顶上

使用道具 举报

回复
论坛徽章:
67
现任管理团队成员
日期:2012-06-02 02:10:00ITPUB元老
日期:2012-09-12 14:06:14ITPUB社区千里马徽章
日期:2013-06-09 10:15:34季节之章:冬
日期:2012-09-04 11:05:30季节之章:春
日期:2012-09-05 09:20:36优秀写手
日期:2013-12-18 09:29:09马上有房
日期:2014-04-10 13:35:362014年新春福章
日期:2014-04-14 09:54:08马上有车
日期:2014-02-28 16:43:13马上加薪
日期:2014-02-19 11:55:14
25#
发表于 2010-8-19 14:05 | 只看该作者
不错的贴,收藏!

使用道具 举报

回复
论坛徽章:
10
2009日食纪念
日期:2009-07-22 09:30:00雪佛兰
日期:2013-12-18 22:21:22Jeep
日期:2013-12-04 21:41:402013年新春福章
日期:2013-05-27 10:23:002013年新春福章
日期:2013-05-27 10:23:002013年新春福章
日期:2013-05-27 10:23:00双黄蛋
日期:2013-01-13 23:04:422012新春纪念徽章
日期:2012-01-04 11:54:26双黄蛋
日期:2011-06-23 12:19:162014年新春福章
日期:2014-03-24 22:47:17
26#
发表于 2010-9-8 22:43 | 只看该作者
必须学了

使用道具 举报

回复
27#
发表于 2010-11-19 10:05 | 只看该作者
收藏了,慢慢看

使用道具 举报

回复
论坛徽章:
16
授权会员
日期:2005-11-01 10:49:02ITPUB十周年纪念徽章
日期:2011-09-27 16:30:472011新春纪念徽章
日期:2011-02-18 11:43:322010年世界杯参赛球队:南非
日期:2010-05-12 11:08:572010新春纪念徽章
日期:2010-03-01 11:04:542009新春纪念徽章
日期:2009-01-04 14:52:28生肖徽章2007版:狗
日期:2008-10-31 12:50:13生肖徽章2007版:狗
日期:2008-10-24 18:01:04奥运会纪念徽章:排球
日期:2008-10-24 13:30:01生肖徽章2007版:狗
日期:2008-10-20 14:41:16
28#
发表于 2010-11-19 15:53 | 只看该作者
遇到过好几次,in exist 的子查询出现or 导致查询从几秒变成几十分钟的情况
通过union处理了。

直接 or 就没办法优化么?

使用道具 举报

回复
论坛徽章:
16
授权会员
日期:2005-11-01 10:49:02ITPUB十周年纪念徽章
日期:2011-09-27 16:30:472011新春纪念徽章
日期:2011-02-18 11:43:322010年世界杯参赛球队:南非
日期:2010-05-12 11:08:572010新春纪念徽章
日期:2010-03-01 11:04:542009新春纪念徽章
日期:2009-01-04 14:52:28生肖徽章2007版:狗
日期:2008-10-31 12:50:13生肖徽章2007版:狗
日期:2008-10-24 18:01:04奥运会纪念徽章:排球
日期:2008-10-24 13:30:01生肖徽章2007版:狗
日期:2008-10-20 14:41:16
29#
发表于 2010-11-19 16:43 | 只看该作者
原帖由 anlinew 于 2010-8-5 15:39 发表
在使用events来作为诊断依据是有时候可能会漏掉一些session
比如上面执行1分多钟的情况下该session的event始终被统计为容易被大家忽略的 SQL net 事件



刚刚模拟了一下,由于test_filter_hash表在执行那句长的delete时你select 过,所以不需要进行进行db file scatter read了。但是如果我们一开始没有select,或者清空db cache,那么这个wait其实一直是db file scatter read,这说明有时在event中看到的信息可能是上一句,或者内部的第一部执行的等待情况,当前的没有显示出来。

我也解释了我查看别人package执行中发现的等待和我感觉中第一步执行的等待情况相同,和当前的等待情况不同的问题。

使用道具 举报

回复
论坛徽章:
16
授权会员
日期:2005-11-01 10:49:02ITPUB十周年纪念徽章
日期:2011-09-27 16:30:472011新春纪念徽章
日期:2011-02-18 11:43:322010年世界杯参赛球队:南非
日期:2010-05-12 11:08:572010新春纪念徽章
日期:2010-03-01 11:04:542009新春纪念徽章
日期:2009-01-04 14:52:28生肖徽章2007版:狗
日期:2008-10-31 12:50:13生肖徽章2007版:狗
日期:2008-10-24 18:01:04奥运会纪念徽章:排球
日期:2008-10-24 13:30:01生肖徽章2007版:狗
日期:2008-10-20 14:41:16
30#
发表于 2010-11-19 20:03 | 只看该作者
原帖由 anlinew 于 2010-8-5 15:39 发表
在使用events来作为诊断依据是有时候可能会漏掉一些session
比如上面执行1分多钟的情况下该session的event始终被统计为容易被大家忽略的 SQL net 事件



10046的trace  虽然看上去全部等待的是  SQL*Net message from client ,其实这时间  SQL*Net message from client 的等待时间很短。
大部分还是cpu的等待。 EVENT的信息是上一步的等待
********************************************************************************

delete   FROM  test_filter_hash t1
   where created < (select  max(created) from test_filter_hash t2 where t2.object_id=t1.object_id
  GROUP BY t2.object_id
  )

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1     29.72      29.16          0    1872451          0           0
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        2     29.72      29.16          0    1872451          0           0

Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 150

Rows     Row Source Operation
-------  ---------------------------------------------------
      0  DELETE  TEST_FILTER_HASH (cr=1872451 pr=0 pw=0 time=29163167 us)
      0   FILTER  (cr=1872451 pr=0 pw=0 time=29163158 us)
  10398    TABLE ACCESS FULL TEST_FILTER_HASH (cr=190 pr=0 pw=0 time=10485 us)
   9852    SORT GROUP BY NOSORT (cr=1872261 pr=0 pw=0 time=29111090 us)
  19704     TABLE ACCESS FULL TEST_FILTER_HASH (cr=1872261 pr=0 pw=0 time=29030998 us)


Elapsed times include waiting on following events:
lapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  SQL*Net message to client                       1        0.00          0.00
  SQL*Net message from client                     1        0.08          0.08
********************************************************************************

使用道具 举报

回复

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

本版积分规则 发表回复

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