mysql GROUP BY、DISTINCT、ORDER BY語句優(yōu)化

GROUP BY、DISTINCT、ORDERBY這幾類子句比較類似，GROUP BY默認(rèn)也是要進(jìn)行ORDERBY排序的，筆者在本書中 把它們歸為一類，優(yōu)化的思路也是類似的。

在成都網(wǎng)站設(shè)計、成都網(wǎng)站建設(shè)中從網(wǎng)站色彩、結(jié)構(gòu)布局、欄目設(shè)置、關(guān)鍵詞群組等細(xì)微處著手，突出企業(yè)的產(chǎn)品/服務(wù)/品牌，幫助企業(yè)鎖定精準(zhǔn)用戶，提高在線咨詢和轉(zhuǎn)化，使成都網(wǎng)站營銷成為有效果、有回報的無錫營銷推廣。創(chuàng)新互聯(lián)建站專業(yè)成都網(wǎng)站建設(shè)十年了，客戶滿意度97.8%，歡迎成都創(chuàng)新互聯(lián)客戶聯(lián)系。

可以考慮的優(yōu)化方式如下。

1、盡量對較少的行進(jìn)行排序。

2、如果連接了多張表，ORDERBY的列應(yīng)該屬于連接順序的第一張表。

3、利用索引排序，如果不能利用索引排序，那么EXPLAIN查詢語句將會看到有filesort。

4、GROUP BY、ORDERBY語句參考的列應(yīng)該盡量在一個表中，如果不在同一個表中，那么可以考慮冗余一些列，或者合并表。

5、需要保證索引列和ORDERBY的列相同，且各列均按相同的方向進(jìn)行排序。

6、增加sort_buffer_size。 sort_buffer_size是為每個排序線程分配的緩沖區(qū)的大小。增加該值可以加快ORDERBY或GROUP BY操作。但是，這是為每 個客戶端分配的緩沖區(qū)，因此不要將全局變量設(shè)置為較大的值，因為每個需要排序的連接都會分配sort_buffer_size大小的內(nèi)存。

7、增加read_rnd_buffer_size。 當(dāng)按照排序后的順序讀取行時，通過該緩沖區(qū)讀取行，從而避免搜索硬盤。將該變量設(shè)置為較大的值可以大大改進(jìn)ORDER BY的性能。但是，這是為每個客戶端分配的緩沖區(qū)，因此你不應(yīng)將全局變量設(shè)置為較大的值。相反，只用為需要運行大查詢 的客戶端更改會話變量即可。

8、改變tmpdir變量指向基于內(nèi)存的文件系統(tǒng)或其他更快的磁盤。 如果MySQL服務(wù)器正作為復(fù)制從服務(wù)器被使用，那么不應(yīng)將“--tmpdir”設(shè)置為指向基于內(nèi)存的文件系統(tǒng)的目錄，或者當(dāng)服務(wù) 器主機重啟時將要被清空的目錄。因為，對于復(fù)制從服務(wù)器，需要在機器重啟時仍然保留一些臨時文件，以便能夠復(fù)制臨時表 或執(zhí)行LOADDATAINFILE操作。如果在服務(wù)器重啟時丟失了臨時文件目錄下的文件，那么復(fù)制將會失敗。

9、指定ORDERBY NULL。 默認(rèn)情況下，MySQL將排序所有GROUP BY的查詢，如果想要避免排序結(jié)果所產(chǎn)生的消耗，可以指定ORDERBY NULL。 例如：SELECT count(*) cnt, cluster_id FROM stat GROUP BY cluster_id ORDER BY NULL LIMIT 10; ·

10、優(yōu)化GROUP BY WITHROLLUP。 GROUP BY WITHROLLUP可以方便地獲得整體分組的聚合信息（superaggregation），但如果存在性能問題，可以考慮在應(yīng)用層實現(xiàn)這個功能，這樣往往會更高效，伸縮性也更佳。

11、使用非GROUP BY的列來代替GROUP BY的列。 比如，原來是“GROUP BYxx_name,yy_name”，如果GROUP BYxx_id可以得到一樣的結(jié)果，那么使用GROUP BYxx_id也是可 行的。

12、可以考慮使用Sphinx等產(chǎn)品來優(yōu)化GROUP BY語句，一般來說，它可以有更好的可擴展性和更佳的性能。

MySQL常用優(yōu)化方案

語句執(zhí)行后，會顯示三個字段： Query_ID（執(zhí)行ID） | Duration（持續(xù)時間）| Query（查詢語句） ；

拿到后Query_ID后，可執(zhí)行 show profile for query Query_ID ，查看詳細(xì)的準(zhǔn)備時間，執(zhí)行時間、執(zhí)行結(jié)束（ preparing、executing、end ）等。

顯示用戶正在運行的線程，需要注意的是，除了 root 用戶能看到所有正在運行的線程外，其他用戶都只能看到自己正在運行的線程，看不到其它用戶正在運行的線程。除非單獨個這個用戶賦予了PROCESS 權(quán)限。

顯示字段包含： User| Host| db | Command | Time| State| Info 等。

解析語句，查詢是否命中索引，及，命中何種索引，用以判斷是否符合我們的預(yù)期。

返回字段包含： select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra 等。

select_type 常見類型：

(1) SIMPLE(簡單SELECT，不使用UNION或子查詢等)

(2) PRIMARY(子查詢中最外層查詢，查詢中若包含任何復(fù)雜的子部分，最外層的select被標(biāo)記為PRIMARY)

(3) UNION(UNION中的第二個或后面的SELECT語句)

(4) SUBQUERY(子查詢中的第一個SELECT，結(jié)果不依賴于外部查詢)

table 常見類型：

顯示這一行的數(shù)據(jù)是關(guān)于哪張表的.

有時不是真實的表名字,看到的是derivedx(x是個數(shù)字,我的理解是第幾步執(zhí)行的結(jié)果)

type 常見類型：

對表訪問方式，表示MySQL在表中找到所需行的方式，又稱“訪問類型”。

常用的類型有： ALL、index、range、 ref、eq_ref、const、system、NULL （從左到右，性能從差到好）

possible_keys

指出MySQL能使用哪個索引在表中找到記錄，查詢涉及到的字段上若存在索引，則該索引將被列出，但不一定被查詢使用（該查詢可以利用的索引，如果沒有任何索引顯示 null）

該列完全獨立于EXPLAIN輸出所示的表的次序。這意味著在possible_keys中的某些鍵實際上不能按生成的表次序使用。

如果該列是NULL，則沒有相關(guān)的索引。在這種情況下，可以通過檢查WHERE子句看是否它引用某些列或適合索引的列來提高你的查詢性能。如果是這樣，創(chuàng)造一個適當(dāng)?shù)乃饕⑶以俅斡肊XPLAIN檢查查詢

key

key列顯示MySQL實際決定使用的鍵（索引），必然包含在possible_keys中

如果沒有選擇索引，鍵是NULL。要想強制MySQL使用或忽視possible_keys列中的索引，在查詢中使用FORCE INDEX、USE INDEX或者IGNORE INDEX。

key_len

表示索引中使用的字節(jié)數(shù)，可通過該列計算查詢中使用的索引的長度，非實際長度，為最大可能長度。

注：不損失精確性的情況下，長度越短越好。

ref

列與索引的比較，表示上述表的連接匹配條件，即哪些列或常量被用于查找索引列上的值。

rows

估算出結(jié)果集行數(shù)，表示MySQL根據(jù)表統(tǒng)計信息及索引選用情況，估算的找到所需的記錄所需要讀取的行數(shù)；

extra

該列包含MySQL解決查詢的詳細(xì)信息,有以下幾種情況：

(1).Distinct

一旦MYSQL找到了與行相聯(lián)合匹配的行，就不再搜索了

(2).Not exists

MYSQL優(yōu)化了LEFT JOIN，一旦它找到了匹配LEFT JOIN標(biāo)準(zhǔn)的行，就不再搜索了

(3).Range checked for each

Record（index map:#）

沒有找到理想的索引，因此對于從前面表中來的每一個行組合，MYSQL檢查使用哪個索引，并用它來從表中返回行。這是使用索引的最慢的連接之一

(4).Using filesort

看到這個的時候，查詢就需要優(yōu)化了。MYSQL需要進(jìn)行額外的步驟來發(fā)現(xiàn)如何對返回的行排序。它根據(jù)連接類型以及存儲排序鍵值和匹配條件的全部行的行指針來排序全部行；

(5).Using temporary

看到這個的時候，查詢需要優(yōu)化了。這里，MYSQL需要創(chuàng)建一個臨時表來存儲結(jié)果，這通常發(fā)生在對不同的列集進(jìn)行ORDER BY上，而不是GROUP BY上；

(6).Using index

列數(shù)據(jù)是從僅僅使用了索引中的信息而沒有讀取實際的行動的表返回的，這發(fā)生在對表的全部的請求列都是同一個索引的部分的時候。

(7).Using where

使用了WHERE從句來限制哪些行將與下一張表匹配或者是返回給用戶。如果不想返回表中的全部行，并且連接類型ALL或index，這就會發(fā)生，或者是查詢有問題。

mysql如何優(yōu)化以下語句，查詢耗時太久了？

根據(jù)所描述的問題，可嘗試在mms_profitcenter 的FOrderID ，F(xiàn)Suffix列上建立索引，再查詢試試。 下面提供30種mysql常用優(yōu)化方法供參考：

1.對查詢進(jìn)行優(yōu)化，應(yīng)盡量避免全表掃描，首先應(yīng)考慮在 where 及 order by 涉及的列上建立索引。

2.應(yīng)盡量避免在 where 子句中使用!=或操作符，否則將引擎放棄使用索引而進(jìn)行全表掃描。

3.應(yīng)盡量避免在 where 子句中對字段進(jìn)行 null 值判斷，否則將導(dǎo)致引擎放棄使用索引而進(jìn)行全表掃描，如：

select id from t where num is null

可以在num上設(shè)置默認(rèn)值0，確保表中num列沒有null值，然后這樣查詢：

select id from t where num=0

4.應(yīng)盡量避免在 where 子句中使用 or 來連接條件，否則將導(dǎo)致引擎放棄使用索引而進(jìn)行全表掃描，如：

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.下面的查詢也將導(dǎo)致全表掃描：

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

若要提高效率，可以考慮全文檢索。

6.in 和 not in 也要慎用，否則會導(dǎo)致全表掃描，如：

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

對于連續(xù)的數(shù)值，能用 between 就不要用 in 了：

select id from t where num between 1 and 3

7.如果在 where 子句中使用參數(shù)，也會導(dǎo)致全表掃描。因為SQL只有在運行時才會解析局部變量，但優(yōu)化程序不能將訪問計劃的選擇推遲到運行時；它必須在編譯時進(jìn)行選擇。然而，如果在編譯時建立訪問計劃，變量的值還是未知的，因而無法作為索引選擇的輸入項。如下面語句將進(jìn)行全表掃描：

select id from t where num=@num

可以改為強制查詢使用索引：

select id from t with(index(索引名)) where num=@num

8.應(yīng)盡量避免在 where 子句中對字段進(jìn)行表達(dá)式操作，這將導(dǎo)致引擎放棄使用索引而進(jìn)行全表掃描。如：

select id from t where num/2=100

應(yīng)改為:

select id from t where num=100*2

9.應(yīng)盡量避免在where子句中對字段進(jìn)行函數(shù)操作，這將導(dǎo)致引擎放棄使用索引而進(jìn)行全表掃描。如：

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

select id from t where datediff(day,createdate,'2005-11-30')=0--'2005-11-30'生成的id

應(yīng)改為:

select id from t where name like 'abc%'

select id from t where createdate='2005-11-30' and createdate'2005-12-1'

10.不要在 where 子句中的“=”左邊進(jìn)行函數(shù)、算術(shù)運算或其他表達(dá)式運算，否則系統(tǒng)將可能無法正確使用索引。

11.在使用索引字段作為條件時，如果該索引是復(fù)合索引，那么必須使用到該索引中的第一個字段作為條件時才能保證系統(tǒng)使用該索引，否則該索引將不會被使用，并且應(yīng)盡可能的讓字段順序與索引順序相一致。

12.不要寫一些沒有意義的查詢，如需要生成一個空表結(jié)構(gòu)：

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

這類代碼不會返回任何結(jié)果集，但是會消耗系統(tǒng)資源的，應(yīng)改成這樣：

create table #t(...)

13.很多時候用 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)

14.并不是所有索引對查詢都有效，SQL是根據(jù)表中數(shù)據(jù)來進(jìn)行查詢優(yōu)化的，當(dāng)索引列有大量數(shù)據(jù)重復(fù)時，SQL查詢可能不會去利用索引，如一表中有字段sex，male、female幾乎各一半，那么即使在sex上建了索引也對查詢效率起不了作用。

15.索引并不是越多越好，索引固然可以提高相應(yīng)的 select 的效率，但同時也降低了 insert 及 update 的效率，因為 insert 或 update 時有可能會重建索引，所以怎樣建索引需要慎重考慮，視具體情況而定。一個表的索引數(shù)最好不要超過6個，若太多則應(yīng)考慮一些不常使用到的列上建的索引是否有必要。

16.應(yīng)盡可能的避免更新 clustered 索引數(shù)據(jù)列，因為 clustered 索引數(shù)據(jù)列的順序就是表記錄的物理存儲順序，一旦該列值改變將導(dǎo)致整個表記錄的順序的調(diào)整，會耗費相當(dāng)大的資源。若應(yīng)用系統(tǒng)需要頻繁更新 clustered 索引數(shù)據(jù)列，那么需要考慮是否應(yīng)將該索引建為 clustered 索引。

17.盡量使用數(shù)字型字段，若只含數(shù)值信息的字段盡量不要設(shè)計為字符型，這會降低查詢和連接的性能，并會增加存儲開銷。這是因為引擎在處理查詢和連接時會逐個比較字符串中每一個字符，而對于數(shù)字型而言只需要比較一次就夠了。

18.盡可能的使用 varchar/nvarchar 代替 char/nchar ，因為首先變長字段存儲空間小，可以節(jié)省存儲空間，其次對于查詢來說，在一個相對較小的字段內(nèi)搜索效率顯然要高些。

19.任何地方都不要使用 select * from t ，用具體的字段列表代替“*”，不要返回用不到的任何字段。

20.盡量使用表變量來代替臨時表。如果表變量包含大量數(shù)據(jù)，請注意索引非常有限（只有主鍵索引）。

21.避免頻繁創(chuàng)建和刪除臨時表，以減少系統(tǒng)表資源的消耗。

22.臨時表并不是不可使用，適當(dāng)?shù)厥褂盟鼈兛梢允鼓承├谈行?，例如，?dāng)需要重復(fù)引用大型表或常用表中的某個數(shù)據(jù)集時。但是，對于一次性事件，最好使用導(dǎo)出表。

23.在新建臨時表時，如果一次性插入數(shù)據(jù)量很大，那么可以使用 select into 代替 create table，避免造成大量 log ，以提高速度；如果數(shù)據(jù)量不大，為了緩和系統(tǒng)表的資源，應(yīng)先create table，然后insert。

24.如果使用到了臨時表，在存儲過程的最后務(wù)必將所有的臨時表顯式刪除，先 truncate table ，然后 drop table ，這樣可以避免系統(tǒng)表的較長時間鎖定。

25.盡量避免使用游標(biāo)，因為游標(biāo)的效率較差，如果游標(biāo)操作的數(shù)據(jù)超過1萬行，那么就應(yīng)該考慮改寫。

26.使用基于游標(biāo)的方法或臨時表方法之前，應(yīng)先尋找基于集的解決方案來解決問題，基于集的方法通常更有效。

27.與臨時表一樣，游標(biāo)并不是不可使用。對小型數(shù)據(jù)集使用 FAST_FORWARD 游標(biāo)通常要優(yōu)于其他逐行處理方法，尤其是在必須引用幾個表才能獲得所需的數(shù)據(jù)時。在結(jié)果集中包括“合計”的例程通常要比使用游標(biāo)執(zhí)行的速度快。如果開發(fā)時間允許，基于游標(biāo)的方法和基于集的方法都可以嘗試一下，看哪一種方法的效果更好。

28.在所有的存儲過程和觸發(fā)器的開始處設(shè)置 SET NOCOUNT ON ，在結(jié)束時設(shè)置 SET NOCOUNT OFF 。無需在執(zhí)行存儲過程和觸發(fā)器的每個語句后向客戶端發(fā)送 DONE_IN_PROC 消息。

29.盡量避免向客戶端返回大數(shù)據(jù)量，若數(shù)據(jù)量過大，應(yīng)該考慮相應(yīng)需求是否合理。

30.盡量避免大事務(wù)操作，提高系統(tǒng)并發(fā)能力。