qileilove

　　優化目標

　　1、減少 IO 次數

　　IO永遠是數據庫最容易瓶頸的地方，這是由數據庫的職責所決定的，大部分數據庫操作中超過90%的時間都是 IO 操作所占用的，減少 IO 次數是 SQL 優化中需要第一優先考慮，當然，也是收效最明顯的優化手段。

　　2、降低 CPU 計算

　 　除了 IO 瓶頸之外，SQL優化中需要考慮的就是 CPU 運算量的優化了。order by， group by，distinct … 都是消耗 CPU 的大戶(這些操作基本上都是 CPU 處理內存中的數據比較運算)。當我們的 IO 優化做到一定階段之后，降低 CPU 計算也就成為了我們 SQL 優化的重要目標

　　優化方法

　　1、改變 SQL 執行計劃

　 　明確了優化目標之后，我們需要確定達到我們目標的方法。對于 SQL 語句來說，達到上述2個目標的方法其實只有一個，那就是改變 SQL 的執行計劃，讓他盡量“少走彎路”，盡量通過各種“捷徑”來找到我們需要的數據，以達到 “減少 IO 次數” 和 “降低 CPU 計算” 的目標

　　常見誤區

　　1、count(1)和count(primary_key) 優于 count(*)

　 　很多人為了統計記錄條數，就使用 count(1) 和 count(primary_key) 而不是 count(*) ，他們認為這樣性能更好，其實這是一個誤區。對于有些場景，這樣做可能性能會更差，應為數據庫對 count(*) 計數操作做了一些特別的優化。

　　2、count(column) 和 count(*) 是一樣的

　　這個誤區甚至在很多的資深工程師或者是 DBA 中都普遍存在，很多人都會認為這是理所當然的。實際上，count(column) 和 count(*) 是一個完全不一樣的操作，所代表的意義也完全不一樣。

　　count(column) 是表示結果集中有多少個column字段不為空的記錄；

　　count(*) 是表示整個結果集有多少條記錄；

　　3、select a，b from … 比 select a，b，c from … 可以讓數據庫訪問更少的數據量

　　這個誤區主要存在于大量的開發人員中，主要原因是對數據庫的存儲原理不是太了解。

　 　實際上，大多數關系型數據庫都是按照行(row)的方式存儲，而數據存取操作都是以一個固定大小的IO單元(被稱作 block 或者 page)為單位，一般為4KB，8KB… 大多數時候，每個IO單元中存儲了多行，每行都是存儲了該行的所有字段(lob等特殊類型字段除外)。

　　所以，我們是取一個字段還是多個字段，實際上數據庫在表中需要訪問的數據量其實是一樣的。

　　當然，也有例外情況，那就是我們的這個查詢在索引中就可以完成，也就是說當只取 a，b兩個字段的時候，不需要回表，而c這個字段不在使用的索引中，需要回表取得其數據。在這樣的情況下，二者的IO量會有較大差異。

　　4、order by 一定需要排序操作

　　我們知道索引數據實際上是有序的，如果我們的需要的數據和某個索引的順序一致，而且我們的查詢又通過這個索引來執行，那么數據庫一般會省略排序操作，而直接將數據返回，因為數據庫知道數據已經滿足我們的排序需求了。

　　實際上，利用索引來優化有排序需求的 SQL，是一個非常重要的優化手段

　　5、執行計劃中有 filesort 就會進行磁盤文件排序

　　有這個誤區其實并不能怪我們，而是因為 MySQL 開發者在用詞方面的問題。filesort 是我們在使用 explain 命令查看一條 SQL 的執行計劃的時候可能會看到在 “Extra” 一列顯示的信息。

　　實際上，只要一條 SQL 語句需要進行排序操作，都會顯示“Using filesort”，這并不表示就會有文件排序操作。