楼主: yyp2009

update优化

[复制链接]
论坛徽章:
14
ITPUB9周年纪念徽章
日期:2010-10-08 09:28:52沸羊羊
日期:2015-03-04 14:43:43马上有车
日期:2014-02-18 16:41:112014年新春福章
日期:2014-02-18 16:41:11福特
日期:2013-10-14 21:18:25凯迪拉克
日期:2013-09-23 23:01:572013年新春福章
日期:2013-02-25 14:51:242012新春纪念徽章
日期:2012-01-04 11:49:54ITPUB十周年纪念徽章
日期:2011-11-01 16:19:412011新春纪念徽章
日期:2011-02-18 11:43:33
发表于 2011-1-26 12:01 | 显示全部楼层
IDX_MAIN_ASSET_END_DT          END_DT

看看這個字段的定義,和相關INDEX的distinct key有多少

使用道具 举报

回复
论坛徽章:
47
2011新春纪念徽章
日期:2011-01-04 10:24:02奥迪
日期:2013-11-09 23:09:27保时捷
日期:2013-10-15 20:14:48阿斯顿马丁
日期:2013-10-12 09:11:59三菱
日期:2013-09-14 16:45:56雪铁龙
日期:2013-08-21 12:50:25马自达
日期:2013-08-14 12:51:35ITPUB社区千里马徽章
日期:2013-06-09 10:15:34蓝锆石
日期:2013-04-12 00:10:42劳斯莱斯
日期:2013-11-09 23:09:27
发表于 2011-1-26 13:51 | 显示全部楼层
前面没有仔细看,两表名太像了,TRIM (asset_row_id) 走了函数索引
只update了end_dt 一个字段,只有该字段上的索引IDX_MAIN_ASSET_END_DT会影响UPDATE的速度
update的效率本来就不高,特别是索引列,索引上的Update是先delete再insert的

使用道具 举报

回复
论坛徽章:
47
2011新春纪念徽章
日期:2011-01-04 10:24:02奥迪
日期:2013-11-09 23:09:27保时捷
日期:2013-10-15 20:14:48阿斯顿马丁
日期:2013-10-12 09:11:59三菱
日期:2013-09-14 16:45:56雪铁龙
日期:2013-08-21 12:50:25马自达
日期:2013-08-14 12:51:35ITPUB社区千里马徽章
日期:2013-06-09 10:15:34蓝锆石
日期:2013-04-12 00:10:42劳斯莱斯
日期:2013-11-09 23:09:27
发表于 2011-1-26 14:09 | 显示全部楼层
tph表的IDX_MAIN_ASSET_END_DT索引:

DISTINCT_KEYS CLUSTERING_FACTOR   NUM_ROWS
------------- ----------------- ----------
          874          28999384   86047354

要更新的行数非常多啊。

至于两个表是HASH JOIN半连接而不是循环嵌套,可能优化器认为走TPH的asset_row_id字段上的索引成本更高,可能统计信息需要重新收集,或者你强制走一下,看看是否是优化器选择错误了。

使用道具 举报

回复
论坛徽章:
7
生肖徽章2007版:鸡
日期:2008-01-02 17:35:53生肖徽章2007版:猴
日期:2008-01-02 17:35:53生肖徽章2007版:鼠
日期:2008-01-02 17:35:53嫦娥
日期:2008-07-08 11:25:29奥运会纪念徽章:垒球
日期:2008-07-22 23:37:50奥运会纪念徽章:跳水
日期:2008-07-31 22:00:562010新春纪念徽章
日期:2010-01-04 08:33:08
发表于 2011-1-26 14:15 | 显示全部楼层
性能差主要是在TPH这个表的全表扫描上,
改写成这样试试,
UPDATE xxxxx.tph a
   SET a.end_dt = '20110120'
WHERE a.asset_row_id in (select trim(asset_row_id) from xxxxx.tpk)
   AND a.end_dt = '30001231'
从你贴出来的NUM_ROWS数据看,分析数据应该是旧的,把表和索引先重新分析一下吧。

使用道具 举报

回复
认证徽章
论坛徽章:
58
生肖徽章2007版:马
日期:2009-11-06 23:12:33授权会员
日期:2013-01-10 14:38:592013年新春福章
日期:2013-02-25 14:51:24马自达
日期:2013-08-07 10:54:45红旗
日期:2013-08-09 13:48:48劳斯莱斯
日期:2013-09-12 15:56:37萤石
日期:2013-10-31 08:44:19优秀写手
日期:2013-12-18 09:29:13Jeep
日期:2014-01-14 10:53:432014年新春福章
日期:2014-02-18 16:43:09
发表于 2011-1-26 14:17 | 显示全部楼层
原帖由 iori809 于 2011-1-26 11:49 发表
a.end_dt = '30001231'

这个条件选择性怎么样?




SQL> select 5936420/85625523 from dual;

5936420/85625523
----------------
      .069330029

使用道具 举报

回复
认证徽章
论坛徽章:
58
生肖徽章2007版:马
日期:2009-11-06 23:12:33授权会员
日期:2013-01-10 14:38:592013年新春福章
日期:2013-02-25 14:51:24马自达
日期:2013-08-07 10:54:45红旗
日期:2013-08-09 13:48:48劳斯莱斯
日期:2013-09-12 15:56:37萤石
日期:2013-10-31 08:44:19优秀写手
日期:2013-12-18 09:29:13Jeep
日期:2014-01-14 10:53:432014年新春福章
日期:2014-02-18 16:43:09
发表于 2011-1-26 14:19 | 显示全部楼层
原帖由 wilson2006 于 2011-1-26 14:15 发表
性能差主要是在TPH这个表的全表扫描上,
改写成这样试试,
UPDATE xxxxx.tph a
   SET a.end_dt = '20110120'
WHERE a.asset_row_id in (select trim(asset_row_id) from xxxxx.tpk)
   AND a.end_dt = '30001231'
从你贴出来的NUM_ROWS数据看,分析数据应该是旧的,把表和索引先重新分析一下吧。



不好意思请教一下你怎么看出来的,从NUM_ROWS?

使用道具 举报

回复
论坛徽章:
7
生肖徽章2007版:鸡
日期:2008-01-02 17:35:53生肖徽章2007版:猴
日期:2008-01-02 17:35:53生肖徽章2007版:鼠
日期:2008-01-02 17:35:53嫦娥
日期:2008-07-08 11:25:29奥运会纪念徽章:垒球
日期:2008-07-22 23:37:50奥运会纪念徽章:跳水
日期:2008-07-31 22:00:562010新春纪念徽章
日期:2010-01-04 08:33:08
发表于 2011-1-26 14:49 | 显示全部楼层
原帖由 yyp2009 于 2011-1-26 14:19 发表



不好意思请教一下你怎么看出来的,从NUM_ROWS?

是啊,不过相差不是很大,所以这个不认为是主要导致不走索引的原因,主要原因还是你使用的EXIST

使用道具 举报

回复
认证徽章
论坛徽章:
58
生肖徽章2007版:马
日期:2009-11-06 23:12:33授权会员
日期:2013-01-10 14:38:592013年新春福章
日期:2013-02-25 14:51:24马自达
日期:2013-08-07 10:54:45红旗
日期:2013-08-09 13:48:48劳斯莱斯
日期:2013-09-12 15:56:37萤石
日期:2013-10-31 08:44:19优秀写手
日期:2013-12-18 09:29:13Jeep
日期:2014-01-14 10:53:432014年新春福章
日期:2014-02-18 16:43:09
发表于 2011-1-26 15:03 | 显示全部楼层
聚簇因子过高不是说导致全表扫描的吗?

使用道具 举报

回复
论坛徽章:
7
2011新春纪念徽章
日期:2011-02-18 11:43:342010广州亚运会纪念徽章:羽毛球
日期:2011-03-31 09:40:352010广州亚运会纪念徽章:卡巴迪
日期:2011-04-26 13:46:28ITPUB十周年纪念徽章
日期:2011-11-01 16:26:292012新春纪念徽章
日期:2012-01-04 11:57:36ITPUB 11周年纪念徽章
日期:2012-10-09 18:16:00优秀写手
日期:2013-12-18 09:29:11
发表于 2011-1-26 16:19 | 显示全部楼层
楼主试试这样修改那个exists呢:
insert into xxxxx.tph a
select ..,
       case when a.end_dt='30001231' then '20110120' else a.end_dt end end_dt,
       ..
from xxxxx.tph b
left join xxxxx.tpk c
on TRIM (c.asset_row_id) = b.asset_row_id)

使用道具 举报

回复
论坛徽章:
7
生肖徽章2007版:鸡
日期:2008-01-02 17:35:53生肖徽章2007版:猴
日期:2008-01-02 17:35:53生肖徽章2007版:鼠
日期:2008-01-02 17:35:53嫦娥
日期:2008-07-08 11:25:29奥运会纪念徽章:垒球
日期:2008-07-22 23:37:50奥运会纪念徽章:跳水
日期:2008-07-31 22:00:562010新春纪念徽章
日期:2010-01-04 08:33:08
发表于 2011-1-27 18:44 | 显示全部楼层

回复 #18 yyp2009 的帖子

试过我写的SQL吗?执行计划如何贴出来看看,
有谁说过聚簇因子过高肯定导致全表扫描吗?一个叫做**id的列,一般来说选择性应该是足够高,导致索引成本比表成本低很多才对,
如果你认为CBO选择全表扫描是因为聚簇因子的话,加上提示比较一下强制使用索引的成本如何就知道了。

使用道具 举报

回复

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

本版积分规则 发表回复

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