[zz]sql優化相關

源地址：http://www.cnblogs.com/xuxiaoshuan/p/3831481.

瞭解優化前須要知道如下內容：

1 sql語法

2 sql操做執行順序

3 數據庫管理系統的查詢優化器採用的優化方法

 4元操做：1數據的查找基本操做是 表掃描（table scan）， 2索引直接獲取(index seek)  固然因此是創建在排序上的，若是索引的字段大部分都是重複值，那麼索引效果也不會太3

Bookmark Lookup

 

限制性規則：

1 不要超過5個表以上的連接

2 視圖嵌套不要超過2個

 

具體要點：

1 select 時，選擇所需的列，而不是 select * . 緣由： sql的執行過程是解析器，預處理器，優化器，查詢執行引擎，存儲過程。 若是是select * ,會致使優化器沒法完成覆蓋索引；返回內容的容量增長，會增長網絡傳輸的開銷 和IO的開銷。

 

2 鏈接多個表時，列名前添加表名。 緣由：這樣能夠減小字段解析的時間，並杜絕了之後擴展形成的歧義。

 

3 合理寫 where子句。緣由： 在join以後的一步就是where,若是在流水線的前期就儘可能裁剪數據量，一定事半功倍。

 

4 減小數據轉換，從表格設計方面杜絕。

 

5 使用臨時表 和 表變量 避免 語句的複雜性。在一些狀況下數據庫會自動使用臨時表

 

6in exists 是雙層循環，IN適合於外表大而內表小的狀況；EXISTS適合於外表小而內表大的狀況。緣由：區別在於 in時會有一個數值的相等檢測，而這個檢測能夠用到外表的索引；而內表須要一個全表排序，因此不能太大。 exists時，是對外表進行表掃描，判斷是否在內表中，此時內表能夠走索引。

 

 

7 儘可能避免對數據字段部分進行運算。緣由：這樣可使用索引。

 

8 將OLAP OLTP模塊分開。前者是聯機分析處理，每每須要掃描整個表；後者是聯機事務處理，每每只關係部分數據。

 

9 使用存儲過程。緣由：能夠被緩存，

 

10 使用索引：單字段 組合 和 覆蓋索引 。緣由：前2者能夠將表掃描變爲索引獲取，後者能夠避免對錶訪問的Lookup過程。

 

11儘可能避免在where子句中使用 != 緣由： 不等會讓引擎進行table scan

 

12 儘可能使用Union 替代 or  緣由： or會讓引擎進行table scan。還有一個解釋是 uniton的條件中比較對象的type是一個肯定的類型，可是Or倒是模糊的。

 

13  explain 分析 具體狀況時根據結果修正

 14 數據庫類型的選擇是否合適（架構層次）：

 

關係型數據庫的最大特色就是事務的一致性：傳統的關係型數據庫讀寫操做都是事務的，具備ACID的特色，這個特性使得關係型數據庫能夠用於幾乎全部對一致性有要求的系統中，如典型的銀行系統。

可是，在網頁應用中，尤爲是SNS應用中，一致性卻不是顯得那麼重要，用戶A看到的內容和用戶B看到同一用戶C內容更新不一致是能夠容忍的，或者說，兩我的看到同一好友的數據更新的時間差那麼幾秒是能夠容忍的，所以，關係型數據庫的最大特色在這裏已經無用武之地，起碼不是那麼重要了。

面向高性能併發讀寫的key-value數據庫：

key-value數據庫的主要特色即便具備極高的併發讀寫性能，Redis,Tokyo Cabinet,Flare就是這類的表明

面向海量數據訪問的面向文檔數據庫：

這類數據庫的特色是，能夠在海量的數據中快速的查詢數據，典型表明爲MongoDB以及CouchDB

面向可擴展性的分佈式數據庫：

這類數據庫想解決的問題就是傳統數據庫存在可擴展性上的缺陷，這類數據庫能夠適應數據量的增長以及數據結構的變化。