提升數據庫查詢性能淺談

1）數據庫設計方面：
a. 對查詢進行優化，應儘可能避免全表掃描，首先應考慮在 where 及 order by 涉及的列上創建索引。
b. 應儘可能避免在 where 子句中對字段進行 null 值判斷，不然將致使引擎放棄使用索引而進行全表掃描，如： select id from t where num is null 能夠在num上設置默認值0，確保表中num列沒有null值，而後這樣查詢： select id from t where num=0
c. 並非全部索引對查詢都有效，SQL是根據表中數據來進行查詢優化的，當索引列有大量數據重複時,查詢可能不會去利用索引，如一表中有字段sex，male、female幾乎各一半，那麼即便在sex上建了索引也對查詢效率起不了做用。
d. 索引並非越多越好，索引當然能夠提升相應的 select 的效率，但同時也下降了 insert 及 update 的效率，由於 insert 或 update 時有可能會重建索引，因此怎樣建索引須要慎重考慮，視具體狀況而定。一個表的索引數最好不要超過6個，若太多則應考慮一些不常使用到的列上建的索引是否有必要。
e. 應儘量的避免更新索引數據列，由於索引數據列的順序就是表記錄的物理存儲順序，一旦該列值改變將致使整個表記錄的順序的調整，會耗費至關大的資源。若應用系統須要頻繁更新索引數據列，那麼須要考慮是否應將該索引建爲索引。
f. 儘可能使用數字型字段，若只含數值信息的字段儘可能不要設計爲字符型，這會下降查詢和鏈接的性能，並會增長存儲開銷。這是由於引擎在處理查詢和鏈接時會逐個比較字符串中每個字符，而對於數字型而言只須要比較一次就夠了。
g. 儘量的使用 varchar/nvarchar 代替 char/nchar ，由於首先變長字段存儲空間小，能夠節省存儲空間，其次對於查詢來講，在一個相對較小的字段內搜索效率顯然要高些。
h. 儘可能使用表變量來代替臨時表。若是表變量包含大量數據，請注意索引很是有限（只有主鍵索引）。
i. 避免頻繁建立和刪除臨時表，以減小系統表資源的消耗。
j. 臨時表並非不可以使用，適當地使用它們可使某些例程更有效，例如，當須要重複引用大型表或經常使用表中的某個數據集時。可是，對於一次性事件，最好使用導出表。
k. 在新建臨時表時，若是一次性插入數據量很大，那麼可使用 select into 代替 create table，避免形成大量 log ，以提升速度；若是數據量不大，爲了緩和系統表的資源，應先create table，而後insert。
l. 若是使用到了臨時表，在存儲過程的最後務必將全部的臨時表顯式刪除，先 truncate table ，而後 drop table ，這樣能夠避免系統表的較長時間鎖定。
2)SQL語句方面：
a. 應儘可能避免在 where 子句中使用!=或<>操做符，不然將引擎放棄使用索引而進行全表掃描。
b. 應儘可能避免在 where 子句中使用 or 來鏈接條件，不然將致使引擎放棄使用索引而進行全表掃描，如： select id from t where num=10 or num=20 能夠這樣查詢： select id from t where num=10 union all select id from t where num=20
c. in 和 not in 也要慎用，不然會致使全表掃描，如： select id from t where num in(1,2,3) 對於連續的數值，能用 between 就不要用 in 了： select id from t where num between 1 and 3
d. 下面的查詢也將致使全表掃描： select id from t where name like ‘%abc%’
f. 應儘可能避免在 where 子句中對字段進行表達式操做，這將致使引擎放棄使用索引而進行全表掃描。如： select id from t where num/2=100 應改成: select id from t where num=100*2
g. 應儘可能避免在where子句中對字段進行函數操做，這將致使引擎放棄使用索引而進行全表掃描。如： select id from t where substring(name,1,3)=’abc’–name以abc開頭的id select id from t where datediff(day,createdate,’2005-11-30′)=0–‘2005-11-30’生成的id 應改成: select id from t where name like ‘abc%’ select id from t where createdate>=’2005-11-30′ and createdate<’2005-12-1′
h. 不要在 where 子句中的「=」左邊進行函數、算術運算或其餘表達式運算，不然系統將可能沒法正確使用索引。
i. 不要寫一些沒有意義的查詢，如須要生成一個空表結構： select col1,col2 into #t from t where 1=0 這類代碼不會返回任何結果集，可是會消耗系統資源的，應改爲這樣： create table #t(…)
i. 不要寫一些沒有意義的查詢，如須要生成一個空表結構： select col1,col2 into #t from t where 1=0 這類代碼不會返回任何結果集，可是會消耗系統資源的，應改爲這樣： create table #t(…)
k. 任何地方都不要使用 select * from t ，用具體的字段列表代替「*」，不要返回用不到的任何字段。
l. 儘可能避免使用遊標，由於遊標的效率較差，若是遊標操做的數據超過1萬行，那麼就應該考慮改寫。
m. 儘可能避免向客戶端返回大數據量，若數據量過大，應該考慮相應需求是否合理。
n. 儘可能避免大事務操做，提升系統併發能力。
3)java方面：重點內容
a.儘量的少造對象。
b.合理擺正系統設計的位置。大量數據操做，和少許數據操做必定是分開的。大量的數據操做，確定不是ORM框架搞定的。，
c.使用jDBC連接數據庫操做數據
d.控制好內存，讓數據流起來，而不是所有讀到內存再處理，而是邊讀取邊處理；
e.合理利用內存，有的數據要緩存
如何優化數據庫，如何提升數據庫的性能?

解答：
1） 硬件調整性能 最有可能影響性能的是磁盤和網絡吞吐量,解決辦法擴大虛擬內存，並保證有足夠能夠擴充的空間；把數據庫服務器上的沒必要要服務關閉掉；把數據庫服務器和主域服務器分開；把SQL數據庫服務器的吞吐量調爲最大；在具備一個以上處理器的機器上運行SQL。
2）調整數據庫
若對該表的查詢頻率比較高，則創建索引；創建索引時，想盡對該表的全部查詢搜索操做， 按照where選擇條件創建索引，儘可能爲整型鍵創建爲有且只有一個簇集索引，數據在物理上按順序在數據頁上，縮短查找範圍，爲在查詢常用的所有列創建非簇集索引，能最大地覆蓋查詢；可是索引不可太多，執行UPDATE DELETE INSERT語句須要用於維護這些索引的開銷量急劇增長；避免在索引中有太多的索引鍵；避免使用大型數據類型的列爲索引；保證每一個索引鍵值有少數行。
3）使用存儲過程
應用程序的實現過程當中，可以採用存儲過程實現的對數據庫的操做盡可能經過存儲過程來實現，由於存儲過程是存放在數據庫服務器上的一次性被設計、編碼、測試，並被再次使用，須要執行該任務的應用能夠簡單地執行存儲過程，而且只返回結果集或者數值，這樣不只可使程序模塊化，同時提升響應速度，減小網絡流量，而且經過輸入參數接受輸入，使得在應用中完成邏輯的一致性實現。
4）應用程序結構和算法

創建查詢條件索引僅僅是提升速度的前提條件，響應速度的提升還依賴於對索引的使用。由於人們在
使用SQL時每每會陷入一個誤區，即太關注於所得的結果是否正確，特別是對數據量不是特別大的數據庫操做時，是否創建索引和使用索引的好壞對程序的響應速度並不大，所以程序員在書寫程序時就忽略了不一樣的實現方法之間可能存在的性能差別，這種性能差別在數據量特別大時或者大型的或是複雜的數據庫環境中（如聯機事務處理OLTP或決策支持系統DSS）中表現得尤其明顯。在工做實踐中發現，不良的SQL每每來自於不恰當的索引設計、不充份的鏈接條件和不可優化的where子句。在對它們進行適當的優化後，其運行速度有了明顯地提升！