第一篇：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
性能优化原则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)
begin
select a.* into #temp1 from SF_MZCFK a(nolock),SF_CFMXK b(nolock)
end
else begin
select a.* into #temp1 from SF_NMZCFK a(nolock),SF_NCFMXK b(nolock)
end
--改为
Insert into #temp1 select a.*
from SF_MZCFK a(nolock),SF_CFMXK b(nolock)
If @@rowcount=0
Begin
Insert into #temp1 select a.*
from SF_NMZCFK a(nolock),SF_NCFMXK b(nolock)
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
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 ….
第二篇：LoadRunner测试SQL语句性能
本次通过loadRunner录制SQLServer介绍一下如何测试一个sql语句或存储过程的执行性能。主要分如下几个步骤完成：
第一步、测试准备
第二步、配置ODBC数据源
第三步、录制SQL语句在Sql Server查询分析器中的运行过程
第四步、优化录制脚本，设置事务
第五步、改变查询数量级查看SQL语句的性能
第六步、在controller中运行脚本
下面开始具体的介绍：
测试准备阶段我们首先要确认测试数据库服务器：我们可以在本地安装SQL SERVER数据库服务端及客户端，也可以确定一台装好的SQL SERVER服务器。
接下来，准备测试数据：对数据库测试时我们要考虑的不是SQL语句是否能够正确执行，而是在某数量级的情况下SQL语句的执行效率及数据库服务的运行情况，所以我们分别准备不同数量级的测试数据，即根据实际的业务情况预估数据库中的记录数，在本次讲解中我们不考虑业务逻辑也不考虑数据表之间的关系，我们只建立一张表，并向此表中加入不同数量级的数据，如分别加入1000条、10000条、50000条、100000条数据查看某SQL语句的执行效率。在查询分析器中运行如下脚本：
--创建测试数据库
create database loadrunner_test;
use loadrunner_test
--创建测试数据表
create table test_table
(username varchar(50),sex int,age int,address varchar(100),post int)
--通过一段程序插入不同数量级的记录，具体的语法在这里就不多说了
declare@iint
set@i=0
while@i<1000//循环1000次，可以根据测试数据情况改变插入条数
begin
BEGIN TRAN T1
insert into test_table(username,sex,age,address,post)values('户瑞海'+cast(@i as varchar),@i-1,@i+1,'北京市和平里'+cast(@i as varchar)+'号',123456);
IF @@ERROR <> 0
begin
rollback;
select @@error
end
else
begin
commit;
set@i=@i+1
end
end
好了，执行完上述语句后，建立的数据表中已经有1000条记录了，下面进行第二步的操作，配置ODBC数据源，为了能让loadrunner能够通过ODBC协议连接到我们建立的SQL SERVER数据路，我们需要在本机上建立ODBC数据源，建立方法如下：
控制面板—性能和维护—管理工具—数据源（ODBC）--添加，在列表中选择SQL SERVER点击完成，根据向导输入数据源名称，链接的服务器，下一步，输入链接数据库的用户名和密码，更改链接的数据库，完成ODBC的配置，如果配置正确的话，在最后一步点击“测试数据源”，会弹出测试成功的提示。
配置好ODBC数据源后就要录制SQL语句在查询分析器中的执行过程了：
1、打开loadrunner，选择ODBC协议
2、在start recording中的application type 选择win32 application；program to record中录入SQL SERVER查询分析器的路径“..安装目录isqlw.exe”
3、开始录制，首先通过查询分析器登录SQL SERVER，在打开的查询分析器窗口中输入要测试的SQL语句，如“select * from test_table;”
4、在查询分析器中执行该语句，执行完成后，结束录制
好了，现在就可以看到loadrunner生成的脚本了（由于脚本过长，在这里就不粘贴了，有需要的朋友可以加我QQ，我把脚本发给你们），通过这些语句，我们可以看出，登录数据库的过程、执行SQL语句的过程。
接下来，我们来优化脚本，我们分别为数据库登录部分和执行SQL语句的部分加一个事物，在增加一个double的变量获取事务执行时间，简单内容如下：
Action()
{double trans_time;//定义一个double型变量用来保存事务执行时间
lr_start_transaction(“sqserver_login”);//设置登录事务的开始
lrd_init(&InitInfo, DBTypeVersion);//初始化链接（下面的都是loadrunner生成的脚本了，大家可以通过帮助查到每个函数的意思）
lrd_open_context(&Ctx1, LRD_DBTYPE_ODBC, 0, 0, 0);
lrd_db_option(Ctx1, OT_ODBC_OV_ODBC3, 0, 0);
lrd_alloc_connection(&Con1, LRD_DBTYPE_ODBC, Ctx1, 0 /*Unused*/, 0);
………………
trans_time=lr_get_transaction_duration(“sqserver_login”);//获得登录数据库的时间lr_output_message(“sqserver_login事务耗时 %f 秒”, trans_time);//输出该时间
lr_end_transaction(“sqserver_login”, LR_AUTO);//结束登录事务
lr_start_transaction(“start_select”);//开始查询事务
lrd_cancel(0, Csr2, 0 /*Unused*/, 0);
lrd_stmt(Csr2, “select * from test_table;rn”,-1, 1, 0 /*None*/, 0);//此句为执行的SQL lrd_bind_cols(Csr2, BCInfo_D42, 0);
lrd_fetch(Csr2,-10, 1, 0, PrintRow24, 0);
……………..trans_time=lr_get_transaction_duration(“start_select”);//获得该SQL的执行时间
lr_output_message(“start_select事务耗时 %f 秒”, trans_time);//输出该时间
lr_end_transaction(“start_select”, LR_AUTO);//结束查询事务
优化后，在执行上述脚本后，就可以得到登录到数据库的时间及运行select * from test_table这条语句的时间了，当然我们也可以根据实际情况对该条语句进行参数化，可以测试多条语句的执行时间，也可以将该语句改为调用存储过程的语句来测试存储过程的运行时间。
接下来把该脚本在controller中运行，设置虚拟用户数，设置集合点，这些操作我就不说了，但是值得注意的是，没有Mercury 授权的SQL SERVER用户license，在运行该脚本时回报错，提示“You do not have a license for this Vuser type.Please contact Mercury Interactive to renew your license.”我们公司穷啊买不起loadrunner，所以我也无法继续试验，希望有license朋友们监控一下运行结果！
最起码在VUGen中运行该脚本我们可以得到任意一个SQL语句及存储过程的执行时间，如果我们测试的B/S结构的程序，我们也可以通过HTML协议录制的脚本在CONTROLLER中监控SQL SERVER服务器的性能情况，这样两方面结合起来就可以对数据库性能做一个完整的监控了。
第三篇：SQL语句的优化方法
SQL语句的优化方法
1.1注释使用
在语句中多写注释，注释不影响SQL语句的执行效率。增加代码的可读性。
1.2对于事务的使用
尽量使事务处理达到最短，如果事务太长最好按功能将事务分开执行(如：可以让用户在界面上多几步操作)。事务太长很容易造成数据库阻塞，用户操作速度变慢或死机情况。
1.3对于与数据库的交互
尽量减少与数据库的交互次数。如果在前端程序写有循球访问数据库操作，最好写成将数据一次读到前端再进行处理或者写成存储过程在数据库端直接处理。
1.4对于SELECT *这样的语句，不要使用SELECT *这样的语句，而应该使用SELECT table1.column1这样的语句，明确指出要查询的列减少数据的通讯量并且这样的代码可读性好，便于维护。
1.5尽量避免使用游标
它占用大量的资源。如果需要row-by-row地执行，尽量采用非光标技术,如：在客户端循环，用临时表，Table变量，用子查询，用Case语句等等。如果使用了游标，就要尽量避免在游标循环中再进行表连接的操作。
1.6尽量使用count(1)
count函数只有在统计表中所有行数时使用，而且count(1)比count(*)更有效率。
1.7IN和EXISTS
EXISTS要远比IN的效率高。里面关系到full table scan和range scan。几乎将所有的IN操作符子查询改写为使用EXISTS的子查询。
1.8注意表之间连接的数据类型
避免不同类型数据之间的连接。
1.9尽量少用视图
对视图操作比直接对表操作慢,可以用stored procedure来代替她。特别的是不要用视图嵌套,嵌套视图增加了寻找原始资料的难度。我们看视图的本质：它是存放在服务器上的被优化好了的已经产生了查询规划的SQL。对单个表检索数据时，不要使用指向多个表的视图，直接从表检索或者仅仅包含这个表的视图上读，否则增加了不必要的开销,查询受到干扰。
1.10没有必要时不要用DISTINCT和ORDER BY
这些动作可以改在客户端执行，它们增加了额外的开销。
1.11避免相关子查询
一个列的标签同时在主查询和where子句中的查询中出现，那么很可能当主查询中的列值改变之后，子查询必须重新查询一次。查询嵌套层次越多，效率越低，因此应当尽量避免子查询。如果子查询不可避免，那么要在子查询中过滤掉尽可能多的行。
1.1注意UNion和`UNion all 的区别
UNION all执行效率高。
1.1外键关联的列应该建立索引
(如子表id)主子表单据肯定要建视图，2个表的关联以2个表中的MainID为关系，所以，需要给子表的MainID单独建索引，这将很大地提高视图的速度。例如Gy_InOutSub中的InoutMainid增加索引。
第四篇：.Net+SQL Server企业应用性能优化笔记3——SQL查询语句
在上一篇文章中我们使用了几种方法来确定瓶颈，找到瓶颈，下面再回顾一下：
LoadRunner压力测试+Windows计数器，这种方法主要是找出大概的性能问题是在哪台服务器，主要是哪个资源紧张。
ANTS Profiler+SQL Server Profiler，这两个工具的完美搭配可以准确的定位性能是出在哪个函数，哪个SQL语句上。
如果性能问题是出在程序上，那么就要根据业务对程序中的函数进行调整，可能是函数中的写法有问题，算法有问题，这种调整如果不能解决问题的话，那么 就要从架构上进行考虑，我们是不是应该使用这种技术，有没有替代的方案来实现同样的业务功能？举个简单的例子，假设经过跟踪发现，一个负责生成图表的函数 存在性能问题，尤其是在压力测试情况下性能问题尤为严重。原来的图表生成是完全基于GDI+在Web服务器上根据数据进行复杂的绘图，然后将绘出的图片保 存在磁盘上，然后在HTML中添加Img标签来引用图片的地址。现在使用GDI+会消耗大量内存和CPU，而算法上也没有太大的问题，那么这种情况下我们 就需要考虑修改架构，不使用GDI+ 绘图的方式，或者是使用异步绘图的方式。既然绘图会消耗大量的服务器资源，那么一种解决办法就是将绘图的操作从服务器转移到客户端。使用 SilverLight技术，在用户打开网页是只是下载了一个SilverLight文件，该文件负责调用Web服务器的Web服务，将绘图所需的数据获 取下来，然后在客户端绘图展现出来。这样服务器只提供WebService的数据访问接口，不需要做绘图操作。
.net上的优化我暂时不表，今天主要讲数据库的优化。使用ANTS Profiler+SQL Server Profiler我们可以精确定位某个业务操作对应的数据库脚本或者存储过程。ANTS Profiler告诉我们一个方法在调用的时候花了10秒的时间，那么我们就可以使用VS打开源代码，找到该放入，然后找到对应调用的存储过程，这里也许 一个方法里面调用了多个数据层方法，调用了多个存储过程。将调用的这些存储过程记下了，然后在SQL Server Provider的跟踪文件里面去找调用该存储过程花费的Duration。
据的时间
一般企业应用或小型应用中数据库服务器和Web服务器要不是就在同一个机房，同一个局域网，或者干脆是同一台机器，这种情况下网络传输速度是很快 的，所以我们不考虑网络传送上面的时间。那么就得出：的存储过程的Duration)
代码中的时间得到了，SQL Server中的时间（也就是Duration字段）得到了，那么就可以判断出打开该页面各个服务器所花费的时间，从而找到我们要优化的方向，是存储过程 还是C#代码。如果是存储过程，那么通过查询SQL Server Profiler中内容可以找到具体是哪一个存储过程消耗的时间最长。
“射人先射马，擒贼先擒王。”多个存储过程被调用，如果性能出在数据库服务器上，那么进行性能优化时首先要调优的是最大Duration最大的存储 过程，另外还有就是Reads很大的存储过程。如果Duration很大但是Reads和Writes都不算特别大，那么有可能是以下原因：
1.这个存储过程相关的资源正在被其他事务占用，也就是说该存储过程被阻塞所以才花了那么多时间。这种情况只需要把该存储过程提出，多执行几 次，看是不是仍然Duration很大但Reads不大。
2.存储过程本身很复杂，里面的T-SQL语句就是五六百行，编译出的执行计划也是一堆，里面进行了大量的逻辑判断、大量函数的调用，这种情 况下进行调优就比较痛苦了。实际上这次我调优的这个项目就是如此，抓取出来的存储过程尽是复杂的逻辑，少则两三百行代码，多则五六百行，里面还有大量的用 户定义函数的调用。对于这种存储过程，我接下来会专门写篇博客介绍下我们这个项目是如何调优的。
3.程序读取的数据不多，但是需要对数据进行大量的运算。哈希联接、聚合函数、DISTINCT、UNION等都是比较耗CPU的。如果是这 种情况那就看能不能建立索引或者改写法进行调优。
前面说的是Duration大而Reads小的情况，当然更常见的情况是Duration和Reads都很大。那么我们就将主要精力集中在如何减小 Reads上。造成Reads很多的原因大概有以下几种：
1.没有建立相应的索引。对表t1进行查询，条件是where c2=abc返回c1,c2,c3三个字段，那么这种情况下如果没有对c2建立非聚集索引（c1是主键，建立了聚集索引），那么这个查询将会进行“聚集索 引扫描”，本来可能只查出几条记录的，结果要把表的所有记录都扫描一篇，自然Reads就高了。解决办法就是建立相应的索引，比如这里只需要对c2字段建 立非聚集索引，然后将c3字段作为包行列就行了。如果只是最c2字段建立非聚集索引，那么前面说到的查找在进行了“非聚集索引查找”后还会进行“键查找” 来找到c3列的值，所以要建立的正确的索引才行。
2.不符合SARG原则。查询如果不符合SARG原则，那么即使建立了索引也没法使用。SARG就是查询参数的意思，具体怎么写才符合 SARG，大家可以百度，已经有很多相关文章了，我就不累述。
3.涉及的业务数据量大。也就是说即使建立了正确的索引，查询也符合SARG使用到了该索引，但是由于涉及的数据量太大了，所以Reads仍 然很大。这种情况就不能再从索引和查询入手，而只能从数据库的设计入手。是否能够增加适当的冗余字段，对数据库进行反范式化，或者如果数据的实时性要
求不 高的话则可以建立中间汇总表，使用SQL作业来维护这个中间汇总表，查询的时候只查询该中间汇总表即可。或者是否可以建立索引视图或者计算列，然后在计算 列中建立索引的方式进行一个预运算，减小实际查询时涉及的数据量。
4.使用了不当的视图。如果对视图的定义很复杂，涉及的表很多，在查询的时候使用了该视图，但是实际上只用到了视图中的一张或两张表，对视图 的查询会造成系统根据视图定义查询其他与该查询不相关的表。所以在使用视图的时候一定要知道视图的定义，不用贪图一时的方便而随便使用视图。
5.不正确的使用了用户定义函数。一个存储过程中几百行代码，出于编写方便，大量的调用了一个用户定义表值函数，而该函数是进行了复杂的查询 和运算才返回结果的。如果数次或者数十次的调用该用户定义表值函数，那么就会进行很多这种复杂的查询和运算，自然Reads也就很大了。解决办法是尽量减 少对这种复制函数的调用，比如一次调用后就将解决保存在表变量或临时表中，接下来再使用的话就使用该表变量或临时表即可。
如果Duration并不大，但是Reads却很大的查询仍然需要需要进行优化。虽然表现出来消耗的时间并不大，但是由于Reads很多，那么说明 要进行大量的IO，在高并发的情况下大量的IO处理不过来会加重磁盘的负担，造成CPU占用率上升，性能降低，这时其Duration就会变大。关于 Duration不大但是Reads很大的情况仍然是前面说到的几点情况，建立相关索引、修改查询语句等便可解决。
第五篇：sql常用语句
//创建临时表空间
create temporary tablespace test_temp
tempfile 'E:oracleproduct10.2.0oradatatestservertest_temp01.dbf'size 32m
autoextend on
next 32m maxsize 2048m
extent management local;
//创建数据表空间
create tablespace test_data
logging
datafile 'E:oracleproduct10.2.0oradatatestservertest_data01.dbf'size 32m
autoextend on
next 32m maxsize 2048m
extent management local;
//创建用户并指定表空间
create user username identified by password
default tablespace test_data
temporary tablespace test_temp;
//给用户授予权限
//一般用户
grant connect,resource to username;
//系统权限
grant connect,dba,resource to username
//创建用户
create user user01 identified by u01
//建表
create table test7272（id number(10),name varchar2(20),age number(4),joindate date default sysdate,primary key(id));
//存储过程
//数据库连接池
数据库连接池负责分配、管理和释放数据库连接
//
//创建表空间
create tablespace thirdspace
datafile 'C:/Program Files/Oracle/thirdspace.dbf' size 10mautoextend on;
//创建用户
create user binbin
identified by binbin
default tablespace firstspace
temporary tablespace temp;
//赋予权限
GRANT CONNECT, SYSDBA, RESOURCE to binbin
//null与""的区别
简单点说null表示还没new出对象，就是还没开辟空间
个对象装的是空字符串。
//建视图
create view viewname
as
sql
//建索引
create index indexname on tablename(columnname)
//在表中增加一列
alter table tablename add columnname columntype
//删除一列
alter table tablename drop columnname
//删除表格内容，表格结构不变
truncate table tableneme
//新增数据
insert into tablename()values()
//直接新增多条数据
insert into tablename()
selecte a,b,c
from tableabc
//更新数据 new除了对象，但是这“”表示
update tablename set columnname=? where
//删除数据
delete from tablename
where
//union语句
sql
union
sql
//case
case
when then
else
end
点击咨询 