第一篇：關于SQL優化的一些思想和原則

關于SQL優化的一些思想和原則

一、優化的目的對應用程序的優化通常可分為兩個方面：源代碼優化和SQL語句優化。由于涉及到對程序邏輯的改變，源代碼的優化在時間成本和風險上代價很高(尤其是對正在使用中的系統進行優化)。另一方面，源代碼的優化對數據庫系統性能的提升收效有限，因為應用程序對數據庫的操作最終要表現為SQL語句對數據庫的操作。

對SQL語句優化有以下一些直接原因：

1.SQL語句是對數據庫(數據)進行操作的惟一途徑，應用程序的執行最終要歸結為SQL語句的執行，SQL語句的效率對數據庫系統的性能起到了決定性的作用。

2.SQL語句消耗了70%～90%的數據庫資源。

3.SQL語句獨立于程序設計邏輯，對SQL語句進行優化不會影響程序邏輯，相對于對程序源代碼的優化，對SQL語句優化在時間成本和風險上的代價都很低。

4.SQL語句可以有不同的寫法，不同的寫法在性能上的差異可能很大。

5.SQL語句易學，難精通。SQL語句的性能往往同實際運行系統的數據庫結構、記錄數量等有關，不存在普遍適用的規律來提升性能。

二、優化數據庫的思想

1、關鍵字段建立索引。

2、使用存儲過程，它使SQL變得更加靈活和高效。

3、備份數據庫和清除垃圾數據。

4、SQL語句語法的優化。

5、清理刪除日志。

三、SQL語句優化的原則

不要以為只有SELECT語句是查詢。實際上，帶有任何WHERE條件的DML(INSERT、UPDATE、DELETE)語句中都包含查詢要求，在后面的文章中，當說到查詢時，不一定只是指SELECT語句，也有可能指DML語句中的查詢部分。

我們知道，SQL語句同其它語言(如C語言)的語句不一樣，它是非過程化(non-procedural)的語句，即當你要取數據時，不需要告訴數據庫通 過何種途徑去取數據，如到底是通過索引取數據，還是應該將表中的每行數據都取出來，然后再通過一一比較的方式取數據(即全表掃描)。

為了實現一個查詢，內核必須為每個查詢定制一個查詢策略，或為取出符合條件的數據生成一個執行計劃(execution plan)。典型的，對于同一個查詢，可能有幾個執行計劃都符合要求，都能得到符合條件的數據。例如，參與連接的表可以有多種不同的連接方法，這取決于連接條件和優化器采用的連接方法。為了在多個執行計劃中選擇最優的執行計劃，優化器必須使用一些實際的指標來衡量每個執行計劃使用的資源(I/0次數、CPU等)，這些資源也就是我們所說的代價(cost)。如果一個執行計劃使用的資源多，我們就說使用執行計劃的代價大。以執行計劃的代價大小作為衡量標準，優化器選擇代價最小的執行計劃作為真正執行該查詢的執行計劃，并拋棄其它的執行計劃。

第二篇：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 ….

第三篇：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增加索引。

第四篇：SQL優化要點總結

SQL優化要點總結

文章比較簡短,但很實用,SQL優化要點總結:

1、盡量避免大表的全表掃描，建立合適的索引,務必注意索引是把雙刃劍，不能濫用，用好則已，用不好傷人害已。

2、能不排序則不排序，除了order by，注意一些隱含的操作也會有排序，比如UNION,DISTINCT操作

3、盡量少用子查詢改用多表聯接，因為子查詢最終優化器也是轉換成多表聯接，當語句很復雜的時候，優化器不一定能轉換對

4、必要時使用Hints干擾執行計劃，優化器不是萬能的，很多時候誤判

5、合理使用動態綁定，語句共享,減少SQL語句的硬解析次數，尤其是OLTP系統，數據倉庫系統后臺ETL計算有循環語句執行需考慮

6、多層嵌套，考慮使用中間表或臨時表做轉儲

7、數據量大考慮建立表分區、索引分區，減少數據檢索范

8、物化視圖的使用,query rewrite特性激動人心

9、在資源充足的情況下充分使用并行，比較常用的場景比如：大索引的創建、大查詢、大批量的DML

第五篇：思想優化工程實施方案

中共射洪縣住房和城鄉建設局委員會 “解放思想大討論”思想優化工程實施方案

一、學習時間：

二、學習地點：

三、參加人員：

四、主 持 人：

五、學習內容：

1、黨的十八大精神。

2、遂寧市委六屆五次全會精神。

3、射洪縣委十二屆四次全會精神。

4、習近平、王岐山同志在第十八屆中央紀律委員會第二次全體會議上的講話。

5、楊洪波同志在縣委常委班子2012民主生活會上的講話。

6、中共射洪縣住房和城鄉建設局委員會2013年黨建工作要點。

7、射洪縣住房和城鄉建設局2013年工作要點。

8、其他。