mysql查詢語句優化

聯表查詢:

1️⃣SELECT ta.sid, ta.instance_id, ta.user_id, *******

FROM t_action ta, t_instance ti

WHERE    ta.status = 3 *******

AND ta.instance_id = ti.sid

ORDER BY ta.sid DESC

LIMIT 10

 這句explain的結果就是: ta:Using index; Using temporary; Using filesort    ti:Using where

 

說明:這裏的ta和ti表 關聯查詢 ta表的instance_id和 ti的sid字段關聯,再經過SID排序

由於ta表裏是沒有game_id的 因此order by的時候 會把ti表的結果給緩存起來

但由於ti表要緩存的數據不少,最後多出的又要放進磁盤內存中,因此就有了using filesort,最後再把磁盤的一併釋放掉;每次查詢都如此往復,天然而然查詢會慢下來.

 

解決方案:將這個查詢語句拆分紅兩句去查詢或者在ta表中野加一個game_id字段 

 

2️⃣SELECT COUNT(sid)

 

FROM T_***

WHERE sid > 0

由於公司數據庫mysql用的是InnoDB而不是myisam, 若是是myisam數據庫就會很快,而InnoDB須要全盤掃描會很慢; 

二者區別: 

對於count()查詢來講MyISAM更有優點

由於MyISAM存儲了表中的行數記錄，執行SELECT COUNT() 的時候能夠直接獲取到結果，而InnoDB須要掃描所有數據後獲得結果。

可是注意一點：對於帶有WHERE 條件的 SELECT COUNT()語句兩種引擎的表執行過程是同樣的，都須要掃描所有數據後獲得結果

 

解決方案:不要一會兒給出結果,進行定時任務緩存處理,當對該表進行修改操做時將緩存刪除; 

 

 

另一些優化的例子:

1)儘可能少用負條件查詢;

假設咱們有一個Order表，表中有一個字段是Status，這個字段有4個值，分別是0=待支付、1=待發貨、2=待收貨、3=已完成。

這時，咱們要查詢全部已經支付的訂單，不少人就會寫這樣的SQL：

select * from Order where Status != 0

這就是一個很差的習慣了。負向條件查詢（例如：!=、not in、not exists）都是不能使用索引的，當Order表中的數據到達必定量級時，這個查詢的效率會急劇的降低。因此，正確的寫法應該是：

select * from Order where Status in (1,2,3)

2)儘可能少用前導模糊查詢;

假設咱們如今要根據用戶的訂單號（OrderNo）查詢用戶的訂單，若是是直接經過SQL查詢的話，儘可能不要使用前導模糊查詢，也就是：

select * from Order where OrderNo like '%param'

或者

select * from Order where OrderNo like '%param%'

由於，前導模糊查詢是沒法命中索引的，因此，會整個數據庫去檢索，效率至關的差，而非前導模糊查詢則是可使用索引的。

所以，咱們儘可能不要把通配符放在前面，改爲下面這樣：

select * from Order where OrderNo like 'param%'

3)儘可能不要在條件字段上加運算;

假設，如今有一個需求，是要查詢2018年整年的訂單數據，咱們就須要經過建立時間（CreateTime）來進行檢索，可是，有些程序員就喜歡這樣寫SQL：

select * from Order where Year(CreateTime)=2018

而後，每次執行時就會發現，查詢的速度異常的慢，致使了大量的請求掛起甚至超時。這是由於，咱們即便在CreateTime上創建了索引，可是，若是使用了運算函數，查詢同樣會進行全表的檢索。

因此，咱們能夠改爲這樣：

select * from Order where CreateTime > '2018-1-1 00:00:00'

4)當查詢容許null的列值時,須要特別注意;

咱們在建立表的字段時，若是這個字段須要做爲索引時，儘可能不要容許Null。由於，單列索引不會存Null值，複合索引不存全部索引列都爲Null的值，因此若是列容許爲Null，可能會獲得「不符合預期」的結果集。

例如：咱們有一個User表，其中有UserName字段記錄了用戶的名字，而且添加了索引。

如今咱們執行了這樣一個查詢：

select * from User where UserName != '小倩'

但結果是這樣的

 那位UserName爲Null的數據並無能包括進來。所以，若是咱們想要包含這個用戶的話，最好可以設置一個默認值。

5)複合索引使用時須要注意順序;

登陸，確定是咱們使用得最多的一個查詢了，爲了保證效率，咱們爲LoginID和Password加上了複合索引。

當咱們使用

select * from User where LoginID = '{LoginID}' and Password = '{Password}'
select * from User where Password = '{Password}' and LoginID = '{LoginID}'

查詢時，都是可以準備的命中索引。當咱們使用：

select * from User where LoginID = '{LoginID}' 

查詢時，也是可以命中索引的。可是，當咱們使用

select * from User where Password = '{Password}' 

查詢時，確沒法命中索引，這是什麼緣由呢？

這是因爲，複合索引對於查詢的順序是很是的銘感的，因此，符合索引中包含了幾種規則，其中就有全列匹配和最左前綴匹配。

當全部列都可以匹配時，雖然查詢的順序上有不一樣，可是查詢優化器會將順序進行調整，以知足適合索引的順序，因此，順序的顛卻是沒有問題的。

可是，若是全部列不能匹配時，就必須知足最左前綴匹配了，也就是，必須按照從左到右的順序進行排列。所以，當咱們創建是索引是<LoginID, Password>時，where Password = '{Password}' 就不知足最左前綴規則，沒法命中索引了。

 6)結果惟一時別愣着;

 

一般，咱們設計User表時，並不會把LoginID做爲主鍵，可是，LoginID確會在業務邏輯中驗證惟一性，所以，若是使用

 

select * from User where LoginID = '{LoginID}'

查詢時，結果必定只有一條。可是，數據庫是不知道的，即便找到了這惟一的一條結果，他也會一直繼續，直到掃描完全部的數據。

所以，在執行這樣的查詢時，咱們能夠優化一下，改爲：

select * from User where LoginID = '{LoginID}' limit 1

這樣，當查詢到結果時，就不會再繼續了。

OVER!