Chinaunix首页 | 论坛 | 博客
  • 博客访问: 811736
  • 博文数量: 167
  • 博客积分: 7173
  • 博客等级: 少将
  • 技术积分: 1671
  • 用 户 组: 普通用户
  • 注册时间: 2009-08-04 23:07
文章分类

全部博文(167)

文章存档

2018年(1)

2017年(11)

2012年(2)

2011年(27)

2010年(88)

2009年(38)

分类: 数据库开发技术

2009-11-29 19:00:50


     从上海来到温州,看了前几天监控的sql语句和数据变化,发现有一条语句的io次数很大,达到了150万次IO,而两个表的数据也就不到20万,为何有如此多的IO次数,下面是执行语句: 

select ws.nodeid,wi.laststepid,wi.curstepid from Workflowinfo wi, 
Workflowstep ws 
where ws.workflowid='402881db1b441e6f011c0cff320e4766' and (wi.laststepid = ws.id or (wi.curstepid = ws.id and isreceived=1 and issubmited =1)) 

  执行IO统计结果如下:

(22 行受影响)
表 
'workflowstep'。扫描计数 1,逻辑读取 23 次,物理读取 0 次,预读 0 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。
表 
'Worktable'。扫描计数 4,逻辑读取 1490572 次,物理读取 0 次,预读 0 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。
表 
'workflowinfo'。扫描计数 4,逻辑读取 12208 次,物理读取 0 次,预读 0 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。
表 
'Worktable'。扫描计数 0,逻辑读取 0 次,物理读取 0 次,预读 0 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。

  执行计划如下:

  

    这里发现:主要是嵌套循环算法占的开销最大。个人感觉是“Or”引起的性能问题,后来根据业务逻辑改写。如下:

    语句修改如下:

  select ws.nodeid,wi.laststepid,wi.curstepid from Workflowinfo wi, Workflowstep ws
where ws.workflowid='402881db1b441e6f011c0cff320e4766' and (wi.laststepid = ws.id) 
union all 
  
select ws.nodeid,wi.laststepid,wi.curstepid from Workflowinfo wi, Workflowstep ws where ws.workflowid='402881db1b441e6f011c0cff320e4766' and  (wi.curstepid = ws.id and isreceived=1 and issubmited =1)

 

   查询IO次数如下:

(22 行受影响)
表 
'workflowinfo'。扫描计数 36,逻辑读取 142 次,物理读取 0 次,预读 0 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。
表 
'workflowstep'。扫描计数 2,逻辑读取 46 次,物理读取 0 次,预读 0 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。

  执行计划如下:

 

   这里发现:成本不在是嵌套循环上的开销了,IO次数大大减少。

   总结:

      这里通过改写”OR“语句成“Union”语句,性能大大提高,用了or语句,数据库优化器无法优化,这里都是用的“嵌套循环算法”,但是使用方式不一样,同样得到不同的结果。

      对于类似的语句,可以将其改写成”Union“ 或”Union All“ 语句。

阅读(999) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~