大牛的經驗之談：數據庫查詢速度優化技巧及解決方案
摘要
從事前端開發的都知道,頁面顯示的數據一定要及時的呈現,否則會影響用戶體現.那么導致頁面加載數據慢或者顯示滯后的原因又是什么呢?
拿自己之前做項目經歷給大家講講吧,之前做后臺,當時的項目實時性都非常高,前端頁面實時顯示要求非常高 ,慢1秒顯示都會導致用戶的投訴,最后沒辦法,通過本地(磁盤)緩存跟數據表分割來解決這一問題.
原因分析
主要原因1: 后臺數據庫中的數據過多,沒做數據優化導致后臺查詢數據很慢
次要原因2: 前端數據請求-解析-展示過程處理不當
次要原因3: 網絡問題所致
那么我們應該怎么做后臺數據優化呢?
解決問題
這里總結了幾種方案,如何提高數據庫查詢的速度,大家參考.
1、緩存，在持久層或持久層之上做緩存
使用ehcache緩存,這個一般用于持久層的緩存，提供持久層、業務層的快速緩存，hibenate默認使用的二級緩存就是ehcache;
2、數據庫表的大字段剝離
假如一個表的字段數有100多個,學會拆分字段,保證單條記錄的數據量很小;
3、恰當地使用索引
必要時建立多級索引,分析MySQL的執行計劃，通過表數據統計等方式協助數據庫走正確的查詢方式，該走索引就走索引，該走全表掃描就走全表掃描;
4、表的拆分
表分區和拆分，無論是業務邏輯上的拆分（如一個月一張報表、分庫）還是無業務含義的分區（如根據ID取模分區）;
5、字段冗余
減少跨庫查詢和大表連接操作;,數據通過單個或多個JOB生成出來，減少實時查詢;
6、從磁盤上做文章
數據存放的在磁盤的內、外磁道上，數據獲取的效率都是不一樣的;
7、放棄關系數據庫的某些特性
引入NoSQL數據庫;
換種思路存放數據，例如搜索中的倒排表;
在上面談到數據庫查詢速度優化方案我們講到了,數據優化的幾種方案。接下來,一起看如何實際到具體的操作上.也就是我們在寫數據時我們應該注意些什么？
1、對查詢進行優化,應盡可能避免全表掃描
首先應考慮在 where 及 order by 涉及的列上建立索引。
下面我們來以一個表中177條數據比較一下,全表掃描與建立索引之后性能的一個比較.
1.1 全表查詢
1.2 建立索引查詢
1.3 結論
從這兩種方式查詢數據庫結果看,建立索引之后查詢速度提高了些,現在數據量還不明顯,如果表中有10萬條速度,差異就會很明顯了.
2、寫數據語句時盡可能減少表的全局掃描
2.1 減少where 字段值null判斷
如何這樣做,就會導致引擎放棄使用索引而進行全表掃描
應該這樣去設置(也就是在沒有值時,我們在存數據庫時自動默認給個o值,而不是什么都不寫):
2.2 應盡量避免在 where 子句中使用!=或<>操作符
這樣寫將導致引擎放棄使用索引而進行全表掃描。
2.3 應盡量避免在 where 子句中使用 or 來連接條件
這樣將導致引擎放棄使用索引而進行全表掃描
可以這樣操作:
2.4 in 和 not in 也要慎用
這樣操作,也會導致全表掃描
以通配符*去查詢所有數據,這樣做也是非常耗時的,我們應該需要什么字段就查詢什么字段.
應該這樣做:
3、不要在條件判斷時進行 算數運算
所以不要在 where 子句中的“=”左邊進行函數、算術運算或其他表達式運算,這樣系統將可能無法正確使用索引
應該這樣做:
4、很多時候用 exists 代替 in 是一個好的選擇
5 論索引技巧
5.1 并不是所有索引對查詢都有效
SQL是根據表中數據來進行查詢優化的，當索引列有大量數據重復時，SQL查詢可能不會去利用索引，如一表中有字段sex，male、female幾乎各一半，那么即使在sex上建了索引也對查詢效率起不了作用。
5.2 索引并不是越多越好
索引固然可以提高相應的 select 的效率，但同時也降低了 insert 及 update 的效率，因為 insert 或 update 時有可能會重建索引，所以怎樣建索引需要慎重考慮，視具體情況而定。一個表的索引數最好不要超過6個，若太多則應考慮一些不常使用到的列上建的索引是否有必要。
5.3 應盡可能的避免更新 clustered 索引數據列
因為 clustered 索引數據列的順序就是表記錄的物理存儲順序，一旦該列值改變將導致整個表記錄的順序的調整，會耗費相當大的資源。若應用系統需要頻繁更新 clustered 索引數據列，那么需要考慮是否應將該索引建為 clustered 索引。
5.4 盡量使用數字型字段
若只含數值信息的字段盡量不要設計為字符型，這會降低查詢和連接的性能，并會增加存儲開銷。這是因為引擎在處理查詢和連接時會逐個比較字符串中每一個字符，而對于數字型而言只需要比較一次就夠了。
6 創建數據庫時應該注意地方
6.1. 盡可能的使用 varchar/nvarchar 代替 char/nchar
因為首先變長字段存儲空間小，可以節省存儲空間，其次對于查詢來說，在一個相對較小的字段內搜索效率顯然要高些。
6.2 用表變量來代替臨時表。
1. 如果表變量包含大量數據，請注意索引非常有限（只有主鍵索引）。
2. 在新建臨時表時，如果一次性插入數據量很大，那么可以使用 select into 代替 create table，避免造成大量 log ，以提高速度；如果數據量不大，為了緩和系統表的資源，應先create table，然后insert。
3. 如果使用到了臨時表，在存儲過程的最后務必將所有的臨時表顯式刪除，先 truncate table ，然后 drop table ，這樣可以避免系統表的較長時間鎖定。
4. 避免頻繁創建和刪除臨時表，以減少系統表資源的消耗。
7. 盡量避免使用游標
1. 因為游標的效率較差，如果游標操作的數據超過1萬行，那么就應該考慮改寫。
2. 使用基于游標的方法或臨時表方法之前，應先尋找基于集的解決方案來解決問題，基于集的方法通常更有效。
3. 與臨時表一樣，游標并不是不可使用。對小型數據集使用 FAST_FORWARD 游標通常要優于其他逐行處理方法，尤其是在必須引用幾個表才能獲得所需的數據時。在結果集中包括“合計”的例程通常要比使用游標執行的速度快。如果開發時間允許，基于游標的方法和基于集的方法都可以嘗試一下，看哪一種方法的效果更好。
8 數據放回時注意什么
8.1 盡量避免大事務操作，提高系統并發能力。
這樣可以有效提高系統的并發能力
8.2 盡量避免向客戶端返回大數據量
若數據量過大，應該考慮相應需求是否合理。
來自：http://www.jianshu.com/p/fea61b518dc4