可能導致查詢緩慢的原因
- 數據量過大
- 表設計不合理
- sql語句寫得不好
- 沒有合理使用索引
SQL查詢語句的優化
- 查詢語句中不要使用 *
- 儘量減少子查詢，使用關聯查詢（left join,right join,inner join）替代
- 減少使用IN或者NOT IN ,使用exists，not exists或者關聯查詢語句替代
- or 的查詢儘量用 union或者union all 代替
(在確認沒有重複數據或者不用剔除重複數據時，union all會更好) - 合理的增加冗餘的字段（減少表的聯接查詢）
- 增加中間表進行優化（這個主要是在統計報表的場景，
後臺開定時任務將數據先統計好，儘量不要在查詢的時候去統計） - 建表的時候能使用數字類型的字段就使用數字類型（type,status…），數字類型的字段作爲條件查詢比字符串的快
- 那些可以過濾掉最大數量記錄的條件必須寫在WHERE子句的最末尾
索引的優化
在數據庫中索引是管理數據排序的一種數據結構，相當於是數據的目錄，用於協助數據查詢，常見的索引實現有B-tree和B+tree
索引的類型
- 主鍵索引
- 唯一索引
- 組合索引
- 普通索引
什麼時候索引不生效
- 使用like關鍵字模糊查詢時，% 放在前面索引不起作用，只有“%”不在第一個位置，索引纔會生效（like ‘%文’–索引不起作用）
- 使用聯合索引時，只有查詢條件中使用了這些字段中的第一個字段，索引纔會生效
- 使用OR關鍵字的查詢，查詢語句的查詢條件中只有OR關鍵字，且OR前後的兩個條件中的列都是索引時，索引纔會生效，否則索引不生效。
- 儘量避免在where子句中使用!=或<>操作符,避免使用in和not in操作，否則引擎將放棄使用索引而進行全表掃描。
- 對查詢進行優化，應儘量避免全表掃描，首先應考慮在where以及order by涉及的列上建立索引。
- 應儘量避免在 where 子句中對字段進行表達式操作，這將導致引擎放棄使用索引而進行全表掃描。如：
select id from t where num/2=100
應改爲:
select id from t where num=100 * 2 - 儘量避免在where子句中對字段進行函數操作,將導致引擎放棄使用索引而進行全表掃描。
- 不要在 where 子句中的“=”左邊進行函數、算術運算或其他表達式運算，否則系統將可能無法正確使用索引。
- 並不是所有的索引對查詢都有效，sql是根據表中的數據來進行查詢優化的，當索引列有大量數據重複時，sql查詢不會去利用索引，如一表中有字段sex，male，female幾乎各一半，那麼即使在sex上建立了索引也對查詢效率起不了作用。
- 索引並不是越多越好，索引固然可以提高相應的 select 的效率，但同時也降低了 insert 及 update 的效率，因爲 insert 或 update 時有可能會重建索引，所以怎樣建索引需要慎重考慮，視具體情況而定。一般一個表的索引數最好不要超過6個。
- 儘量使用數字型字段，若只含數值信息的字段儘量不要設計爲字符型，這會降低查詢和連接的性能，並會增加存儲開銷。這是因爲引擎在處理查詢和連接時會 逐個比較字符串中每一個字符，而對於數字型而言只需要比較一次就夠了。
- mysql查詢只使用一個索引，因此如果where子句中已經使用了索引的話，那麼order by中的列是不會使用索引的。因此數據庫默認排序可以符合要求的情況下不要使用排序操作，儘量不要包含多個列的排序，如果需要最好給這些列建複合索引。
- order by 索引 ，不起作用的問題（除了主鍵索引之外）：
- 如果select 只查詢索引字段，order by 索引字段會用到索引，要不然就是全表排列；
- 如果有where 條件，比如where vtype=1 order by vtype asc . 這樣order by 也會用到索引！