1.減小 IO 次數數據庫
IO永遠是數據庫最容易瓶頸的地方，這是由數據庫的職責所決定的，大部分數據庫操做中超過90%的時間都是 IO 操做所佔用的，減小 IO 次數是 SQL 優化中須要第一優先考慮，固然，也是收效最明顯的優化手段。性能
2.下降 CPU 計算優化
除了 IO 瓶頸以外，SQL優化中須要考慮的就是 CPU 運算量的優化了。order by, group by,distinct … 都是消耗 CPU 的大戶(這些操做基本上都是 CPU 處理內存中的數據比較運算)。當咱們的 IO 優化作到必定階段以後，下降 CPU 計算也就成爲了咱們 SQL 優化的重要目標排序
優化方法：索引
改變 SQL 執行計劃內存
明確了優化目標以後，咱們須要肯定達到咱們目標的方法。對於 SQL 語句來講，達到上述2個目標的方法其實只有一個，那就是改變 SQL 的執行計劃，讓他儘可能「少走彎路」，儘可能經過各類「捷徑」來找到咱們須要的數據，以達到 「減小 IO 次數」 和 「下降 CPU 計算」 的目標開發
常見誤區class
1.count(1)和count(primary_key) 優於 count(*)原理
不少人爲了統計記錄條數，就使用 count(1) 和 count(primary_key) 而不是 count(*) ，他們認爲這樣性能更好，其實這是一個誤區。對於有些場景，這樣作可能性能會更差，應爲數據庫對 count(*) 計數操做作了一些特別的優化。file
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，是一個很是重要的優化手段
延伸閱讀：MySQL ORDER BY 的實現分析，MySQL 中 GROUP BY 基本實現原理以及 MySQL DISTINCT 的基本實現原理這3篇文章中有更爲深刻的分析，尤爲是第一篇
5.執行計劃中有 filesort 就會進行磁盤文件排序
有這個誤區其實並不能怪咱們，而是由於 MySQL 開發者在用詞方面的問題。filesort 是咱們在使用 explain 命令查看一條 SQL 的執行計劃的時候可能會看到在 「Extra」 一列顯示的信息。
實際上，只要一條 SQL 語句須要進行排序操做，都會顯示「Using filesort」，這並不表示就會有文件排序操做。