SQL语句性能优化

      我也做了很长时间医疗软件,也写过不少sql优化,没有详细记录下来,个人感觉下面转载的更符合医院医疗软件实际业务,很认可大部分所写的原则,固转载过来,以作借鉴。软件的根本还是在于更细更精,在于从客户的实际使用考虑问题。

性能优化原则1:永远避免困境

利用缓存把字典数据取到中间服务器或是客户端替代直接sql查询,如,门诊医生站把字典下载到客户端,减少执行次数。
一次性取数据到客户端,然后再逐条处理,而不是分次取数据,处理好一条数据再取下一条再处理。例:门诊收费取hjcfmxk例子,原来是一张处方条明细都查询一次,查询后再处理,现改为一次把所有明细都取过来,然后一条条处理
尽量减少光标,看能不能用临时表

性能优化原则2:kiss原则

对于where 条件中的左边可以利用索引的字段Keep it simple stupid,左边尽量避免用函数(substring,isnull,upper,lower),参加计算+,-*/
例子1:select * from ZY_BRFYMXK where substring(zxrq,1,8)='20081212‘
  select * from ZY_BRFYMXK where zxrq between '2008121200' and '2008121224'

例子2:

select * from zy_detail_charge where SUBSTRING(patient_id,1,10)= substring('000005090600',1,10)   这句耗时30秒以上

select * from zy_detail_charge where patient_id like substring('000005090600',1,10)+'%'  这句耗时2秒以内

性能优化原则3:尽可能利用到索引

例:select * from ZY_BRFYMXK a(nolock),VW_LSYZK b(nolock) where a.syxh=3 and a.yzxh=b.xh and a.fylb=0
select * from ZY_BRFYMXK a(nolock),VW_LSYZK b(nolock) where a.syxh=3 and a.yzxh=b.xh and a.fylb=0 and b.syxh=3

性能优化原则4:or,避而远之

对于索引字段尽力避免用or,普通字段可以用or,解决要么分解成多个sql,要么用业务规则避免,
例:declare @rq1 ut_rq16,@syxh ut_syxh
select @rq1='20081201'
select @syxh=157
select * from BQ_FYQQK WHERE (syxh=@syxh or @syxh is null)
select * from BQ_FYQQK WHERE syxh=@syxh

性能优化原则5:避免大批量数据取到前台

例: select * from ZY_BRSYK cyrq between ‘20080901’ and ‘20081201‘,对于大医院每天100多人,90天是9000条数据

性能优化原则6:事务,尽可能的短吧

所有计算、对临时表的更新都应但放在事务外,事务中最好只有更新和插入正式表操作.因为事务中产生的锁只有在commit tran是才会释放。

性能优化原则7:热表,留在最后吧

热表是频繁调用的表。如:sf_mzcfk,
    zy_brfymxk,bq_fyqqk.
   对于热表尽量放在事务最后:这样锁的时间短。大家都坚持这样,死锁的可能性就小。如果都是热表各个存储过程更新表的顺序应当一样这样可以避免死锁

性能优化原则8:创建临时表一定要避免在事务中作

如create #tempXX (…)
Select *  into #tempXX   from …
因为创建临时表会锁tempdb的系统表
例:生成#temp1放在事务内外,用sp_lock2 ‘’观察结果
if object_id('tempdb..#temp1','U') is not null
 drop table #temp1
begin tran
select * into #temp1 from ZY_BRSYK where ryrq>'20080901‘
select * from #temp1
waitfor delay '00:00:10'
commit

性能优化原则9:大的报表查询避免与正常业务碰撞

如果没有查询服务器,那要在存储过程中限制不能操作加上如:
declare @rq1 ut_rq16,
 @rq2  ut_rq16,
 @now ut_rq16
select @rq1=convert(varchar(8),getdate(),112)+'08:00:00'
select @rq1=convert(varchar(8),getdate(),112)+'11:30:00'
select @now=convert(char(8),getdate(),112)+convert(char(8),getdate(),8)
if @now>@rq1 and @now<@rq2
begin
 select '上午繁忙时间段不能作此查询'
 return
end

性能优化原则10:存储过程避免大的if…else…

这个常出项在业务相同表不同的存储过程中,因为这样常到if …else …原来医技接口中很多这种存储过程,当时把门诊住院业务放在一个存储过程中。这样最大的问题是sql server会根据sql语句来compile存储,这个过程会生成优化计划,决定用那个索引。如果存储过程用到门诊表compile一下,到用到住院表是发现不对,又会compile一下,这样不停compile.compile很号时间要1-2秒,而且一个存储过成在compile是,所有调用这个存储过程的进程都要在排队等候,因为他会独占锁这个存储过程
  例:usp_yjjk_getwzxxm_old.sql,后改为:
      usp_yjjk_getwzxxm.sql, usp_yjjk_getwzxxm_mz.sql,
      usp_yjjk_getwzxxm_zy.sql

性能优化原则11:进攻是最好的防守

在普通编程语句对于数据校验总是用防守办法先判断,后再作相应处理。而在sql中先处理再判断性能会好很多。
--更新药品库存。
If  exists(select 1 from YK_YKZKC WHERE idm=100 and kcsl>50 )
begin
    update YK_YKZKC  set kcsl=kcsl-50 where idm=100
End
Else begin
      rollback tran
Select  ‘F库存不够’
return
end

--改为
update YK_YKZKC  set kcsl=kcsl-50 where idm=100 and kcsl>50
If @@rowcount<=0
Begin
Rollbakc tran
Select  ‘F库存不够’
end

--取未执行的医技项目,日表没有数据就到年表中查找
if exists(select a.* from SF_MZCFK a (nolock),SF_CFMXK b (nolock)
where a.xh=b.cfxh and a.patid=@patid and b.yjqrbz=0 and a.cflx not in(1,2,3,6))
begin
    select a.* into #temp1 from SF_MZCFK a (nolock),SF_CFMXK b (nolock)
    where a.xh=b.cfxh and a.patid=@patid  and b.yjqrbz=0 and a.cflx not in(1,2,3,6)
end
else begin
    select a.* into #temp1 from SF_NMZCFK a (nolock),SF_NCFMXK b (nolock)
    where a.xh=b.cfxh and a.patid=@patid  and b.yjqrbz=0 and a.cflx not in(1,2,3,6)
end

--改为
Insert into #temp1 select  a.*
 from SF_MZCFK a (nolock),SF_CFMXK b (nolock)
where a.xh=b.cfxh and a.patid=@patid  and b.yjqrbz=0 and a.cflx not in(1,2,3,6)
If @@rowcount=0
Begin
Insert into #temp1 select  a.*
 from SF_NMZCFK a (nolock),SF_NCFMXK b (nolock)
where a.xh=b.cfxh and a.patid=@patid  and b.yjqrbz=0 and a.cflx not in(1,2,3,6)
end

性能优化原则12:trig最后的手段

Trig(触发器)的处理的处理机制是满足条件时就会在源语句后面加上trig中的代码进行执行。
它有两个致命的弊端:(1)不清楚有trig的人会对于执行结果感到迷惑。如常有在插入一张表如果主键是indentity的值常取用select @@identity。但如是有trig,tring中有表插入操作,这时的@@identity可能就不是想要的值。(2)trig会束缚选择。如:有一套单据主表和明细表,当明细表的金额更新时,要同步主表的金额,当程序是一条条更新明细时用trig的作法是每当更新一条明细记录时都算一处所有明细表的总金额,再去更新主表的金额。这样有多少条明细就要算多少次,好的作法是不要trig,直接在sql语句中明细更新完明后,一次性算出总金额每条单据的总金额,再更新主表的金额。
对于trig如果有其他手段就一定要避免用trig.

性能优化原则13:用户说好才是真的好

1)有时sql语句性能难以优化,但用户对于系统响应速度还是不满意。这时可以从业务分析处理。
如:我们退费模块录入发票号原来是用fph like ‘XXX%’。用户报怨慢,后来改为先用fph=‘XXX’来查,如查不到再fph like ‘XXX%’。这样在绝大部情况下速度都非常快,同时也满足小部分情况下模糊查询的需求。
如:我们的程序要查日表和年表。如果通过日表union表视图去查会非常慢,性能也难以优化。程序改为普通情况下不查年表,用户勾上年表标志时才查年表。
(2)查询统计很多数据时间比较长,就以查询完一部分数据后可以显示这部分数据或是用提示,这样用户清楚系统在作事情也知道大概进度。这样情绪上会好很多。
(3)查询模块常有一进入时也默认一个查询,如果性能好,查询又合用户心意,这种设计非常好,如果性能不好,那就不是好的设计。用户对于进入都困难的模块是没有好感的。
(4)有户的耐心与查询出的记录成正比。用户痛恨等待很久却没有查询出记录。
    对于非常慢的查询,如果有些子查询非常快可以先作这样查询以避免查询很久却没有数据出来的情况。
如:按病历号查在院病人所有费有明细,可以先查一下这个病历是不是有对应病人。

实战技巧1:用exists、in代替distinct

Distinct实际上是先收集再删除这样两步都耗资源。
Exists,in会隐式过滤掉重复的记录
例查自2009年以来有金额大于100的药品的病人

select distinct a.blh,a.hzxm from ZY_BRXXK a(nolock),ZY_BRSYK b(nolock),ZY_BRFYMXK c(nolock) where a.patid=b.patid and b.syxh=c.syxh and c.zxrq>'2009' and c.zje>100
--改为
select a.blh,a.hzxm from ZY_BRXXK a where exists(select 1 from ZY_BRSYK b(nolock),ZY_BRFYMXK c(nolock) where a.patid=b.patid and b.syxh=c.syxh and c.zxrq>'2009'and c.zje>100 )

实战技巧2:缩短union

select …from A,B,C,D,E1
where (E1的条件)
and (其他表联接条件)
union
select …from A,B,C,D,E2
where (E2的条件)
and (其他表接接条件)
改为
select …from A,B,C,D,(select ...
from E1where (E1条件)
union
select …from E2where ( E2条件)) E where (其他条件)
当涉及ABCD表部分耗资源而E1,E2不耗资源时是这样,如果反过来则改后的性能不一定好。

查2009年4月后入院的在院病人在2905病区发生的所有费用明细
select a.hzxm,b.cyrq,d.ypmc,d.ypgg,c.ypsl/c.dwxs ypsl, c.ypdw
select a.hzxm,b.cyrq,d.ypmc,d.ypgg,c.ypsl/c.dwxs ypsl, c.ypdw
from ZY_BRXXK a(nolock),ZY_BRSYK b(nolock),ZY_BRFYMXK c(nolock),YK_YPCDMLK d
where a.patid=b.patid and b.ryrq>'200904' and b.brzt not in(3,8,9) and b.syxh=c.syxh and c.bqdm='2905' and c.idm=d.idm
union all
select a.hzxm,b.cyrq,d.name,d.xmgg,c.ypsl/c.dwxs ypsl, c.ypdw
from ZY_BRXXK a(nolock),ZY_BRSYK b(nolock),ZY_BRFYMXK c(nolock),YY_SFXXMK d
where a.patid=b.patid and b.ryrq>'200904' and b.brzt not in(3,8,9) and b.syxh=c.syxh and c.bqdm='2905' and c.ypdm=d.id and c.idm=0
--改为
select a.hzxm,b.cyrq,d.ypmc,d.ypgg,c.ypsl/c.dwxs ypsl, c.ypdw
from ZY_BRXXK a(nolock),ZY_BRSYK b(nolock),ZY_BRFYMXK c(nolock),
(select ypmc,ypgg,ypdm,idm idm  from YK_YPCDMLK union select name,xmgg,id,0 from YY_SFXXMK ) d
where a.patid=b.patid and b.ryrq>'200904' and b.brzt not in(3,8,9)and b.syxh=c.syxh and c.bqdm='2905' and c.idm=d.idm and c.ypdm=d.ypdm

实战技巧3:合并sql

把表和where条件类似的两个或是多个sql合并为一个sql.
--查2009年以后的普通、急诊、专家挂号人数
declare @ptghs int,@jzghs int,@zjghs int
select @ptghs=0,@jzghs=0,@zjghs=0
select @ptghs=count(*) from GH_GHZDK where ghrq>'2009' and ghlb=0
select @jzghs=count(*) from GH_GHZDK where ghrq>'2009' and ghlb=1
select @zjghs=count(*) from GH_GHZDK where ghrq>'2009' and ghlb=2
select @ptghs,@jzghs,@zjghs
--改为
select @ptghs=0,@jzghs=0,@zjghs=0
select @ptghs=sum(case when ghlb=0 then 1 else 0 end),@jzghs=sum(case when ghlb=1 then 1 else 0 end), @zjghs=sum(case when ghlb=2 then 1 else 0 end)
from GH_GHZDK where ghrq>'2009'
select @ptghs,@jzghs,@zjghs

实战技巧4:去掉游标

把游标当作编程语言的for,do---while的方式,很多情况下都可以去掉,
如果光标中间sql语句只有一条一般都是可以去掉光标改为一句sql。
--查当天出院出院日期在2009年4月1到9日间病人的zfdj,zfje置为0
declare @syxh ut_syxh
declare cur1 cursor for select syxh from ZY_BRSYK where cyrq>='20090401' and cyrq<'20090410'
open cur1
fetch cur1 into @syxh
while @@fetch_status=0  
begin
 update ZY_BRFYMXK set zfdj=0,zfje=0 where syxh=@syxh
 fetch cur1 into @syxh
end
close cur1
deallocate cur1

--改为
update ZY_BRFYMXK set zfdj=0,zfje=0 
from ZY_BRFYMXK a,ZY_BRSYK b
 where  a.syxh=b.syxh and b.cyrq>='20090401' and b.cyrq<'20090410'

实战技巧5:取代count

利用内部函数代替
declare @count int
select * into #tmep1 from ZY_BRFYMXK WHERE zxrq>'200901'
select @count=@@rowcount—可以得到count值
select @count
select @count=count(*) from #tmep1—可以被取代
select @count

利用exists而不count判断有没有记录
declare @count int
Select @count=count(1) from ZY_BRFYMXK WHERE zxrq>'2009‘
If @count>0 … else ….
--改为
If exists(Select 1 from ZY_BRFYMXK WHERE zxrq>'2009’)… else ….

原文地址:https://www.cnblogs.com/cnajian/p/2326160.html