SQL優化

根據慢日志定位慢查詢sql

使用explain等工具分析sql

修改sql或者盡量讓sql走索引

slow_query_log   慢日志狀态

slow_query_log_file 慢日志檔案位址

long_query_time 慢日志記錄的最低查詢時間

explain + 需要分析sql語句

id

select_type

table

partitions

type

possible_keys

key

key_len

ref

rows

filtered

Extra

字段名解釋

id: select查詢的序列号，包含一組數字，表示查詢中執行select子句或操作表的順序

select_type: 表示查詢的類型。

table: 指的就是目前執行的表

partitions: 比對的分區

type: type所顯示的是查詢使用了哪種類型

possible_keys: 顯示可能應用在這張表中的索引，一個或多個。查詢涉及到的字段上若存在索引，則該索引将被列出，但不一定被查詢實際使用。

key: 實際使用的索引，如果為NULL，則沒有使用索引。（可能原因包括沒有建立索引或索引失效）

key_len: 表示索引中使用的位元組數，可通過該列計算查詢中使用的索引的長度，在不損失精确性的情況下，長度越短越好。key_len顯示的值為索引字段的最大可能長度，并非實際使用長度，即key_len是根據表定義計算而得，不是通過表内檢索出的。

ref: 顯示索引的那一列被使用了，如果可能的話，最好是一個常數。哪些列或常量被用于查找索引列上的值。

rows: 根據表統計資訊及索引選用情況，大緻估算出找到所需的記錄所需要讀取的行數，也就是說，用的越少越好

filtered: 按表條件過濾的行百分比

Extra: 列傳回的描述的意義

關鍵字段

system > const>eq_ref > ref>fulltext > ref_or_null > index_merge > unique_subquery >

index_subquery > range > index > all

index ,all 需要優化

system 表隻有一行記錄（等于系統表），這是const類型的特列，平時不會出現，這個也可以忽略不計

const 表示通過索引一次就找到了，const用于比較primary key 或者unique索引。因為隻比對一行資料，是以很快。如将主鍵置于where清單中，MySQL就能将該查詢轉換為一個常量。

eq_ref 唯一性索引掃描，對于每個索引鍵，表中隻有一條記錄與之比對。常見于主鍵或唯一索引掃描

ref 非唯一性索引掃描，傳回比對某個單獨值的所有行，本質上也是一種索引通路，它傳回所有比對某個單獨值的行，然而，它可能會找到多個符合條件的行，是以他應該屬于查找和掃描的混合體。

range 隻檢索給定範圍的行，使用一個索引來選擇行，key列顯示使用了哪個索引，一般就是在你的where語句中出現between、< 、>、in等的查詢，這種範圍掃描索引比全表掃描要好，因為它隻需要開始于索引的某一點，而結束于另一點，不用掃描全部索引。

index Full Index Scan，Index與All差別為index類型隻周遊索引樹。這通常比ALL快，因為索引檔案通常比資料檔案小。（也就是說雖然all和Index都是讀全表，但index是從索引中讀取的，而all是從硬碟讀取

all Full Table Scan 将周遊全表以找到比對的行

extra

extra項

說明

Using filesort

（看到這個的時候，查詢就需要優化了） 表示 mysql會對結果使用一個外部索引排序，而不是從表裡按索引次序讀到相關内容。可能在記憶體或者磁盤上進行排序。mysql 中無法利用索引完成的排序操作稱為“檔案排序”。

Using temporary

（看到這個的時候，查詢需要優化了） 表示 mysql 在對查詢結果排序時使用臨時表。常見于排序order by 和分組查詢 group by 。

Using index

表示相應的select操作中使用了覆寫索引（Covering Index），避免通路了表的資料行，效率不錯。如果同時出現using where，表明索引被用來執行索引鍵值的查找；如果沒有同時出現using where，表明索引用來讀取資料而非執行查找動作。

Using where

表明使用了where過濾

Using join buffer

表明使用了連接配接緩存,比如說在查詢的時候，多表join的次數非常多，那麼将配置檔案中的緩沖區的join buffer調大一些。

impossible where

where子句的值總是false，不能用來擷取任何元組

select tables optimized away

在沒有GROUPBY子句的情況下，基于索引優化MIN/MAX操作或者對于MyISAM存儲引擎優化COUNT(*)操作，不必等到執行階段再進行計算，查詢執行計劃生成的階段即完成優化。

distinct

優化distinct操作，在找到第一比對的元組後即停止找同樣值的動作

1.對查詢進行優化，應盡量避免全表掃描，首先應考慮在 where 及 order by 涉及的列上建立索引。

2.應盡量避免在 where 子句中對字段進行 null 值判斷，否則将導緻引擎放棄使用索引而進行全表掃描，如：

select id from t where num is null

可以在num上設定預設值0，確定表中num列沒有null值，然後這樣查詢：

select id from t where num=0

3.應盡量避免在 where 子句中使用!=或<>操作符，否則将引擎放棄使用索引而進行全表掃描。

4.應盡量避免在 where 子句中使用 or 來連接配接條件，否則将導緻引擎放棄使用索引而進行全表掃描，如：

select id from t where num=10 or num=20

可以這樣查詢：

select id from t where num=10

union all

select id from t where num=20

5.in 和 not in 也要慎用，否則會導緻全表掃描，如：

select id from t where num in(1,2,3)

對于連續的數值，能用 between 就不要用 in 了：

select id from t where num between 1 and 3

6.下面的查詢也将導緻全表掃描：

select id from t where name like '%abc%'

7.應盡量避免在 where 子句中對字段進行表達式操作，這将導緻引擎放棄使用索引而進行全表掃描。如：

select id from t where num/2=100

應改為:

select id from t where num=100*2

8.應盡量避免在where子句中對字段進行函數操作，這将導緻引擎放棄使用索引而進行全表掃描。如：

select id from t where substring(name,1,3)='abc'--name以abc開頭的id

select id from t where name like 'abc%'

9.不要在 where 子句中的“=”左邊進行函數、算術運算或其他表達式運算，否則系統将可能無法正确使用索引。

10.在使用索引字段作為條件時，如果該索引是複合索引，那麼必須使用到該索引中的第一個字段作為條件時才能保證系統使用該索引，否則該索引将不會被使用，并且應盡可能的讓字段順序與索引順序相一緻。

11.不要寫一些沒有意義的查詢，如需要生成一個空表結構：

select col1,col2 into #t from t where 1=0

這類代碼不會傳回任何結果集，但是會消耗系統資源的，應改成這樣：

create table #t(...)

12.很多時候用 exists 代替 in 是一個好的選擇：

select num from a where num in(select num from b)

用下面的語句替換：

select num from a where exists(select 1 from b where num=a.num)

13.并不是所有索引對查詢都有效，SQL是根據表中資料來進行查詢優化的，當索引列有大量資料重複時，SQL查詢可能不會去利用索引，如一表中有字段sex，male、female幾乎各一半，那麼即使在sex上建了索引也對查詢效率起不了作用。

14.索引并不是越多越好，索引固然可以提高相應的 select 的效率，但同時也降低了 insert 及 update 的效率，

因為 insert 或 update 時有可能會重建索引，是以怎樣建索引需要慎重考慮，視具體情況而定。

一個表的索引數最好不要超過6個，若太多則應考慮一些不常使用到的列上建的索引是否有必要。

15.盡量使用數字型字段，若隻含數值資訊的字段盡量不要設計為字元型，這會降低查詢和連接配接的性能，并會增加存儲開銷。

這是因為引擎在處理查詢和連接配接時會逐個比較字元串中每一個字元，而對于數字型而言隻需要比較一次就夠了。

16.盡可能的使用 varchar 代替 char ，因為首先變長字段存儲空間小，可以節省存儲空間，

其次對于查詢來說，在一個相對較小的字段内搜尋效率顯然要高些。

17.任何地方都不要使用 select * from t ，用具體的字段清單代替“*”，不要傳回用不到的任何字段。

18.避免頻繁建立和删除臨時表，以減少系統表資源的消耗。

19.臨時表并不是不可使用，适當地使用它們可以使某些例程更有效，例如，當需要重複引用大型表或常用表中的某個資料集時。但是，對于一次性事件，最好使用導出表。

20.在建立臨時表時，如果一次性插入資料量很大，那麼可以使用 select into 代替 create table，避免造成大量 log ，

以提高速度；如果資料量不大，為了緩和系統表的資源，應先create table，然後insert。

21.如果使用到了臨時表，在存儲過程的最後務必将所有的臨時表顯式删除，先 truncate table ，然後 drop table ，這樣可以避免系統表的較長時間鎖定。

22.盡量避免使用遊标，因為遊标的效率較差，如果遊标操作的資料超過1萬行，那麼就應該考慮改寫。

23.使用基于遊标的方法或臨時表方法之前，應先尋找基于集的解決方案來解決問題，基于集的方法通常更有效。

24.與臨時表一樣，遊标并不是不可使用。對小型資料集使用 FAST_FORWARD 遊标通常要優于其他逐行處理方法，尤其是在必須引用幾個表才能獲得所需的資料時。

在結果集中包括“合計”的例程通常要比使用遊标執行的速度快。如果開發時間允許，基于遊标的方法和基于集的方法都可以嘗試一下，看哪一種方法的效果更好。

25.盡量避免大事務操作，提高系統并發能力。

26.盡量避免向用戶端傳回大資料量，若資料量過大，應該考慮相應需求是否合理。