在日常查詢中，索引或其他數據查找的方法可能不是查詢執行中最高昂的部分，例如：MySQLGROUPBY可能負責查詢執行時間90%還多。MySQL執行GROUPBY時的主要復雜性是計算GROUPBY語句中的聚合函數。UDF聚合函數是一個接一個地獲得構成單個組的所有值。這樣，它可以在移動到另一個組之前計算單個組的聚合函數值。當然，問題在于，在大多數情況下，源數據值不會被分組。來自各種組的值在處理期間彼此跟隨。因此，我們需要一個特殊的步驟。
處理MySQLGROUPBY讓我們看看之前看過的同一張table：mysql>showcreatetabletblG***************************1.row***************************Table:tblCreateTable:CREATETABLE`tbl`(`id`int(11)NOTNULLAUTO_INCREMENT,`k`int(11)NOTNULLDEFAULT'0',`g`int(10)unsignedNOTNULL,PRIMARYKEY(`id`),KEY`k`(`k`))ENGINE=InnoDBAUTO_INCREMENT=2340933DEFAULTCHARSET=latin11rowinset(0.00sec)
并且以不同方式執行相同的GROUPBY語句：
1、MySQL中的IndexOrderedGROUPBY
- mysql>selectk,count(*)cfromtblgroupbykorderbyklimit5;
- +---+---+
- k|c
- +---+---+
- 2|3
- 4|1
- 5|2
- 8|1
- 9|1
- +---+---+
- 5rowsinset(0.00sec)
- mysql>explainselectk,count(*)cfromtblgroupbykorderbyklimit5G
- ***************************1.row***************************
- id:1
- select_type:SIMPLE
- table:tbl
- partitions:NULL
- type:index
- possible_keys:k
- key:k
- key_len:4
- ref:NULL
- rows:5
- filtered:100.00
- Extra:Usingindex
- 1rowinset,1warning(0.00sec)
- 在這種情況下，我們在GROUPBY的列上有一個索引。這樣，我們可以逐組掃描數據并動態執行GROUPBY（低成本）。當我們使用LIMIT限制我們檢索的組的數量或使用“覆蓋索引”時，特別有效，因為順序索引掃描是一種非常快速的操作。
- 如果您有少量組，并且沒有覆蓋索引，索引順序掃描可能會導致大量IO。所以這可能不是最優化的計劃。
- 2、MySQL中的外部排序GROUPBY
- mysql>explainselectSQL_BIG_RESULTg,count(*)cfromtblgroupbyglimit5G
- ***************************1.row***************************
- id:1
- select_type:SIMPLE
- table:tbl
- partitions:NULL
- type:ALL
- possible_keys:NULL
- key:NULL
- key_len:NULL
- ref:NULL
- rows:998490
- filtered:100.00
- Extra:Usingfilesort
- 1rowinset,1warning(0.00sec)
- mysql>selectSQL_BIG_RESULTg,count(*)cfromtblgroupbyglimit5;
- +---+---+
- g|c
- +---+---+
- 0|1
- 1|2
- 4|1
- 5|1
- 6|2
- +---+---+
- 5rowsinset(0.88sec)
- 如果我們沒有允許我們按組順序掃描數據的索引，我們可以通過外部排序（在MySQL中也稱為“filesort”）來獲取數據。你可能會注意到我在這里使用SQL_BIG_RESULT提示來獲得這個計劃。沒有它，MySQL在這種情況下不會選擇這個計劃。
- 一般來說，MySQL只有在我們擁有大量組時才更喜歡使用這個計劃，因為在這種情況下，排序比擁有臨時表更有效（我們將在下面討論）。
- 3、MySQL中的臨時表GROUPBY
- mysql>explainselectg,sum(g)sfromtblgroupbyglimit5G
- ***************************1.row***************************
- id:1
- select_type:SIMPLE
- table:tbl
- partitions:NULL
- type:ALL
- possible_keys:NULL
- key:NULL
- key_len:NULL
- ref:NULL
- rows:998490
- filtered:100.00
- Extra:Usingtemporary
- 1rowinset,1warning(0.00sec)
- mysql>selectg,sum(g)sfromtblgroupbygorderbynulllimit5;
- +---+------+
- g|s
- +---+------+
- 0|0
- 1|2
- 4|4
- 5|5
- 6|12
- +---+------+
- 5rowsinset(7.75sec)
- 在這種情況下，MySQL也會進行全表掃描。但它不是運行額外的排序傳遞，而是創建一個臨時表。此臨時表每組包含一行，并且對于每個傳入行，將更新相應組的值。很多更新！雖然這在內存中可能是合理的，但如果結果表太大以至于更新將導致大量磁盤IO，則會變得非常昂貴。在這種情況下，外部分揀計劃通常更好。請注意，雖然MySQL默認選擇此計劃用于此用例，但如果我們不提供任何提示，它幾乎比我們使用SQL_BIG_RESULT提示的計劃慢10倍。您可能會注意到我在此查詢中添加了“ORDERBYNULL”。這是為了向您展示“清理”臨時表的唯一計劃。沒有它，我們得到這個計劃：mysql>explainselectg,sum(g)sfromtblgroupbyglimit5G***************************1.row***************************id:1select_type:SIMPLEtable:tblpartitions:NULLtype:ALLpossible_keys:NULLkey:NULLkey_len:NULLref:NULLrows:998490filtered:100.00Extra:Usingtemporary;Usingfilesort1rowinset,1warning(0.00sec)
- 在其中，我們獲得了temporary和filesort“兩最糟糕的”提示。MySQL5.7總是返回按組順序排序的GROUPBY結果，即使查詢不需要它（這可能需要昂貴的額外排序傳遞）。ORDERBYNULL表示應用程序不需要這個。您應該注意，在某些情況下-例如使用聚合函數訪問不同表中的列的JOIN查詢-使用GROUPBY的臨時表可能是唯一的選擇。
- 如果要強制MySQL使用為GROUPBY執行臨時表的計劃，可以使用SQL_SMALL_RESULT提示。
- 4、MySQL中的索引基于跳過掃描的GROUPBY前三個GROUPBY執行方法適用于所有聚合函數。然而，其中一些人有第四種方法。
- mysql>explainselectk,max(id)fromtblgroupbykG
- ***************************1.row***************************
- id:1
- select_type:SIMPLE
- table:tbl
- partitions:NULL
- type:range
- possible_keys:k
- key:k
- key_len:4
- ref:NULL
- rows:2
- filtered:100.00
- Extra:Usingindexforgroup-by
- 1rowinset,1warning(0.00sec)
- mysql>selectk,max(id)fromtblgroupbyk;
- +---+---------+
- k|max(id)
- +---+---------+
- 0|2340920
- 1|2340916
- 2|2340932
- 3|2340928
- 4|2340924
- +---+---------+
- 5rowsinset(0.00sec)
- 此方法僅適用于非常特殊的聚合函數：MIN()和MAX()。這些并不需要遍歷組中的所有行來計算值。他們可以直接跳轉到組中的最小或最大組值（如果有這樣的索引）。如果索引僅建立在(K)列上，如何找到每個組的MAX(ID)值？這是一個InnoDB表。記住InnoDB表有效地將PRIMARYKEY附加到所有索引。(K)變為(K,ID)，允許我們對此查詢使用Skip-Scan優化。僅當每個組有大量行時才會啟用此優化。否則，MySQL更傾向于使用更傳統的方法來執行此查詢（如方法＃1中詳述的索引有序GROUPBY）。雖然我們使用MIN()/MAX()聚合函數，但其他優化也適用于它們。例如，如果您有一個沒有GROUPBY的聚合函數（實際上所有表都有一個組），MySQL在統計分析階段從索引中獲取這些值，并避免在執行階段完全讀取表：mysql>explainselectmax(k)fromtblG***************************1.row***************************id:1select_type:SIMPLEtable:NULLpartitions:NULLtype:NULLpossible_keys:NULLkey:NULLkey_len:NULLref:NULLrows:NULLfiltered:NULLExtra:Selecttablesoptimizedaway1rowinset,1warning(0.00sec)
- 過濾和分組
- 我們已經研究了MySQL執行GROUPBY的四種方式。為簡單起見，我在整個表上使用了GROUPBY，沒有應用過濾。當您有WHERE子句時，相同的概念適用：mysql>explainselectg,sum(g)sfromtblwherek>4groupbygorderbyNULLlimit5G***************************1.row***************************id:1select_type:SIMPLEtable:tblpartitions:NULLtype:rangepossible_keys:kkey:kkey_len:4ref:NULLrows:1filtered:100.00Extra:Usingindexcondition;Usingtemporary1rowinset,1warning(0.00sec)
- 對于這種情況，我們使用K列上的范圍進行數據過濾/查找，并在有臨時表時執行GROUPBY。在某些情況下，方法不會發生沖突。但是，在其他情況下，我們必須選擇使用GROUPBY的一個索引或其他索引進行過濾：
- mysql>altertabletbladdkey(g);
- QueryOK,0rowsaffected(4.17sec)
- Records:0Duplicates:0Warnings:0
- mysql>explainselectg,sum(g)sfromtblwherek>1groupbyglimit5G
- ***************************1.row***************************
- id:1
- select_type:SIMPLE
- table:tbl
- partitions:NULL
- type:index
- possible_keys:k,g
- key:g
- key_len:4
- ref:NULL
- rows:16
- filtered:50.00
- Extra:Usingwhere
- 1rowinset,1warning(0.00sec)
- mysql>explainselectg,sum(g)sfromtblwherek>4groupbyglimit5G
- ***************************1.row***************************
- id:1
- select_type:SIMPLE
- table:tbl
- partitions:NULL
- type:range
- possible_keys:k,g
- key:k
- key_len:4
- ref:NULL
- rows:1
- filtered:100.00
- Extra:Usingindexcondition;Usingtemporary;Usingfilesort
- 1rowinset,1warning(0.00sec)
- 根據此查詢中使用的特定常量，我們可以看到我們對GROUPBY使用索引順序掃描（并從索引中“放棄”以解析WHERE子句），或者使用索引來解析WHERE子句（但使用臨時表來解析GROUPBY）。根據我的經驗，這就是MySQLGROUPBY并不總是做出正確選擇的地方。您可能需要使用FORCEINDEX以您希望的方式執行查詢。