本文就如何優化大型數據庫的性能進行了一些探索，提出了優化數據庫訪問性能的若干策略，特別是對SQL語句進行了有效的分析設計的問題，以使其加快執行速度，減少網絡傳輸，能更高效地工作，充分發揮系統的效率。

隨著醫院信息系統模塊的不斷增加，特別是近兩年電子病歷的使用，臨床診療信息大量寫入數據庫，數據量急劇增加，造成業務數據庫非常龐大，業務處理的速度明顯下降。基于這一問題，本文就如何優化大型數據庫的性能進行了一些探索，提出了優化數據庫訪問性能的若干策略，特別是對SQL語句進行了有效的分析設計的問題，以使其加快執行速度，減少網絡傳輸，能更高效地工作，充分發揮系統的效率。

醫院經過多年的信息化建設，取得了顯著成效，信息化由原來的以收費、記帳為主，逐步向臨床醫療、服務病人過渡。隨著醫院信息系統模塊的不斷增加，特別是近兩年電子病歷的使用，臨床診療信息大量寫入數據庫，數據量急劇增加，造成業務數據庫非常龐大，業務處理的速度明顯下降。加之在頻繁的業務數據庫中還要進行大數據量查詢或報表統計，導致在業務處理時經常出現阻塞或死鎖現象，嚴重影響到日常的工作。故如何對數據庫性能在進行優化設計，即提高數據庫的吞吐量、減少用戶等待時間具有重大意義。

傳統的數據庫性能優化主要從操作系統、客戶端應用軟件程序設計、網絡及其它硬件設備等方面來考慮，這種方法只是調整數據庫的周邊環境，只能暫時緩解問題，而不能從根本上解決問題。實際應用中，更多情況是醫院信息系統(包括數據庫系統)都已設計好，只是在運行的過程中隨著數據規模的增大，使得系統出現周期性性能問題。本文提出的醫院數據庫系統性能優化是在己有的硬件設施升級、數據庫的物理設計、關系規范化等方面進行改進基礎之上，對SQL語句進行了有效的分析設計的問題，以使其加快執行速度，減少網絡傳輸，能更高效地工作，充分發揮系統的效率。

1 合理使用索引

提高數據庫查詢速度最有效的方法就是優化索引。索引是建立在實體表上的一種數據組織，它可以提高訪問表中一條或多條記錄的查詢效率，使用索引的目的是為了避免全表掃描，減少磁盤I/O的次數，加快查詢速度，在大型的表中進行索引的建立對加快表的查詢有著重要的意義。但是也并不對任何的數據表都要建立索引，索引通常能提高select、update以及delete語句的性能（當訪問的行較少時），但會降低insert語句的性能（因為需要同時對表和索引進行插入）。此外，過多的索引會產生維護上的開銷，只會降低而不是增加系統的性能，索引的使用要恰到好處。索引使用原則如下：

（1）在經常進行連接，但是沒有指定為外鍵的列上建立索引，而不經常連接的字段則由優化器自動生成索引。

（2）在頻繁進行排序或分組（即進行group by或order by操作）的列上建立索引，而頻繁進行刪除、插入操作的表不要建立過多的索引。

（3）在條件表達式中經常用到的不同值較多的列上建立檢索，在不同值少的列上不要建立索引。比如在雇員表的“性別”列上只有“男”與“女”兩個不同值，因此就沒有必要建立索引，如果在此建立索引不但不會提高查詢效率，反而會嚴重降低更新速度。

（4）如果待排序的列有多個，可以在這些列上建立復合索引（compound index）。盡量使用較窄的索引, 這樣數據頁每頁上能因存放較多的索引行而減少操作。

（5）在查詢中經常作為條件表達式并且不同值較多的列上建立索引，而不同值較少的列上不要建立索引。

（6）當數據庫表更新大數據后, 刪除并重新建立索引來提高查詢速度。

總之，建立索引一定要慎重，對每個索引建立的必要性都要仔細分析，一定要有建立的依據。過多的索引或不充分、不正確的索引對提升數據庫的性能毫無益處。

2 SQL語句優化

SQL語言是一種非常靈活的語言，相同功能的實現常可以用幾種不同的語句來表達，但語句的執行效率可能存在很的差別。因此，任何一個數據庫應用系統中，合理的對SQL語句進行優化將大大的提高整個數據庫系統的性能。所有的SQL語句執行過程分三個階段，分別是進行處理語法分析、執行、讀取數據。

圖1 SQL語句執行過程

在使用SQL時，性能差異在大型的或是復雜的數據庫環境中，如在HIS的一些大型表中表現尤為明顯。經過一段時間的總結，發現SQL語句比較低下的原因主要來自于不恰當的索引設計、不充分的連接條件和不可優化的WHERE子句及其它不恰當的語句操作等，在對它們進行適當的優化后，其運行速度有了明顯提高。下面將從這幾個方面分別進行說明：

2.1 LIKE操作符

LIKE操作符可以應用通配符查詢，里面的通配符組合可能達到幾乎是任意的查詢，但是如果用得不好則會產生性能上的問題，如like 'a%' 使用索引，like ‘%a’ 不使用索引。用 like ‘%a%’ 查詢時，查詢耗時和字段值總長度成正比，所以不能用CHAR類型，而是VARCHAR。

2.2 限制返回行

在查詢Select語句中用Where字句限制返回的行數，避免表掃描，如果返回不必要的數據，浪費了服務器的I/O資源，加重了網絡的負擔降低性能。如果表很大，在表掃描的期間將表鎖住，禁止其他的聯接訪問表，后果嚴重。可以使用TOP語句來限制返回結果。當返回多行數據時，盡可能不使用光標，因為它占用大量的資源，應該使用datastore。

2.3 UNION操作符

UNION在進行表鏈接后會篩選掉重復的記錄，所以在表鏈接后會對所產生的結果集進行排序運算，刪除重復的記錄再返回結果。實際大部分應用中是不會產生重復的記錄，最常見的是過程表與歷史表UNION。推薦采用UNION ALL操作符替代UNION，因為UNION ALL操作只是簡單的將兩個結果合并后就返回。

2.4 Between與IN

Between在某些時候比IN速度更快，Between能夠更快地根據索引找到范圍。如：

select * from YF_KCMX where YPXH in (12,13)

Select * from YF_KCMX where between 12 and 13

一般在GROUP BY 個HAVING字句之前就能剔除多余的行，所以盡量不要用它們來做剔除行的工作。他們的執行順序應該如下最優：select 的Where字句選擇所有合適的行，Group By用來分組個統計行，Having字句用來剔除多余的分組。這樣Group By 個Having的開銷小，查詢快。對于大的數據行進行分組和Having十分消耗資源。如果Group BY的目的不包括計算，只是分組，那么用Distinct更快。

2.5 注意細節

一般不要用如下的字句: “＜＞”, “!=”, “!＞”, “!＜”, “NOT”, “NOT EXISTS”, “NOT IN”, “NOT LIKE”, and “LIKE ‘%500’”，因為他們不走索引全是表掃描。NOT IN會多次掃描表，使用EXISTS、NOT EXISTS ，IN , LEFT OUTER JOIN 來替代，特別是左連接,而Exists比IN更快，最慢的是NOT操作.如果列的值含有空，以前它的索引不起作用， “＜＞”, “!=”, “!＞”,等還是不能優化，用不到索引。

不要在WHere字句中的列名加函數，如Convert，substring等,如果必須用函數的時候，創建計算列再創建索引來替代。還可以變通寫法：

WHERE SUBSTRING(firstname,1,1) = ‘m’

改為：WHERE firstname like ‘m%’（索引掃描）,但MIN() 和 MAX()能使用到合適的索引。

select * form ZY_FYMX where FYDJ ＞ 3000

分析在此語句中若FYDJ是Float類型的，則優化器對其進行優化為Convert(float,3000)，因為3000是個整數，我們應在編程時使用3000.0而不要等運行時讓DBMS進行轉化。同樣字符和整型數據的轉換。應改為：

select * form ZY_FYMX where FYDJ ＞ 3000.00

2.6 避免相關子查詢

一個列的標簽同時在主查詢和where子句中的查詢中出現，那么很可能當主查詢中的列值改變之后，子查詢必須重新查詢一次。查詢嵌套層次越多，效率越低，因此應當盡量避免子查詢。如果子查詢不可避免，那么要在子查詢中過濾掉盡可能多的行。