-
1 # 就能my
-
2 # 愛可生雲資料庫
在日常查詢中,索引或其他資料查詢的方法可能不是查詢執行中最高昂的部分,例如:MySQL GROUP BY 可能負責查詢執行時間 90% 還多。MySQL 執行 GROUP BY 時的主要複雜性是計算 GROUP BY 語句中的聚合函式。UDF 聚合函式是一個接一個地獲得構成單個組的所有值。這樣,它可以在移動到另一個組之前計算單個組的聚合函式值。當然,問題在於,在大多數情況下,源資料值不會被分組。來自各種組的值在處理期間彼此跟隨。因此,我們需要一個特殊的步驟。
處理 MySQL GROUP BY讓我們看看之前看過的同一張table: mysql> show create table tbl G *************************** 1. row *************************** Table: tbl Create Table: CREATE TABLE `tbl` ( `id` int(11) NOT NULL AUTO_INCREMENT, `k` int(11) NOT NULL DEFAULT "0", `g` int(10) unsigned NOT NULL, PRIMARY KEY (`id`), KEY `k` (`k`) ) ENGINE=InnoDB AUTO_INCREMENT=2340933 DEFAULT CHARSET=latin1 1 row in set (0.00 sec)
並且以不同方式執行相同的 GROUP BY 語句:
1、MySQL中 的 Index Ordered GROUP BY
mysql> select k, count(*) c from tbl group by k order by k limit 5;
+---+---+
| k | c |
+---+---+
| 2 | 3 |
| 4 | 1 |
| 5 | 2 |
| 8 | 1 |
| 9 | 1 |
+---+---+
5 rows in set (0.00 sec)
mysql> explain select k, count(*) c from tbl group by k order by k limit 5 G
*************************** 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: Using index
1 row in set, 1 warning (0.00 sec)
在這種情況下,我們在 GROUP BY 的列上有一個索引。這樣,我們可以逐組掃描資料並動態執行 GROUP BY(低成本)。當我們使用 LIMIT 限制我們檢索的組的數量或使用“覆蓋索引”時,特別有效,因為順序索引掃描是一種非常快速的操作。如果您有少量組,並且沒有覆蓋索引,索引順序掃描可能會導致大量 IO。所以這可能不是最最佳化的計劃。
2、MySQL 中的外部排序 GROUP BYmysql> explain select SQL_BIG_RESULT g, count(*) c from tbl group by g limit 5 G
*************************** 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: Using filesort
1 row in set, 1 warning (0.00 sec)
mysql> select SQL_BIG_RESULT g, count(*) c from tbl group by g limit 5;
+---+---+
| g | c |
+---+---+
| 0 | 1 |
| 1 | 2 |
| 4 | 1 |
| 5 | 1 |
| 6 | 2 |
+---+---+
5 rows in set (0.88 sec)
如果我們沒有允許我們按組順序掃描資料的索引,我們可以透過外部排序(在 MySQL 中也稱為“filesort”)來獲取資料。你可能會注意到我在這裡使用 SQL_BIG_RESULT 提示來獲得這個計劃。沒有它,MySQL 在這種情況下不會選擇這個計劃。一般來說,MySQL 只有在我們擁有大量組時才更喜歡使用這個計劃,因為在這種情況下,排序比擁有臨時表更有效(我們將在下面討論)。
3、MySQL中 的臨時表 GROUP BYmysql> explain select g, sum(g) s from tbl group by g limit 5 G
*************************** 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: Using temporary
1 row in set, 1 warning (0.00 sec)
mysql> select g, sum(g) s from tbl group by g order by null limit 5;
+---+------+
| g | s |
+---+------+
| 0 | 0 |
| 1 | 2 |
| 4 | 4 |
| 5 | 5 |
| 6 | 12 |
+---+------+
5 rows in set (7.75 sec)
在這種情況下,MySQL 也會進行全表掃描。但它不是執行額外的排序傳遞,而是建立一個臨時表。此臨時表每組包含一行,並且對於每個傳入行,將更新相應組的值。很多更新!雖然這在記憶體中可能是合理的,但如果結果表太大以至於更新將導致大量磁碟 IO,則會變得非常昂貴。在這種情況下,外部分揀計劃通常更好。請注意,雖然 MySQL 預設選擇此計劃用於此用例,但如果我們不提供任何提示,它幾乎比我們使用 SQL_BIG_RESULT 提示的計劃慢 10 倍 。您可能會注意到我在此查詢中添加了“ ORDER BY NULL ”。這是為了向您展示“清理”臨時表的唯一計劃。沒有它,我們得到這個計劃: mysql> explain select g, sum(g) s from tbl group by g limit 5 G *************************** 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: Using temporary; Using filesort 1 row in set, 1 warning (0.00 sec)在其中,我們獲得了 temporary 和 filesort “兩最糟糕的”提示。MySQL 5.7 總是返回按組順序排序的 GROUP BY 結果,即使查詢不需要它(這可能需要昂貴的額外排序傳遞)。ORDER BY NULL 表示應用程式不需要這個。您應該注意,在某些情況下 - 例如使用聚合函式訪問不同表中的列的 JOIN 查詢 - 使用 GROUP BY 的臨時表可能是唯一的選擇。如果要強制 MySQL 使用為 GROUP BY 執行臨時表的計劃,可以使用 SQL_SMALL_RESULT 提示。
4、MySQL 中的索引基於跳過掃描的 GROUP BY前三個 GROUP BY 執行方法適用於所有聚合函式。然而,其中一些人有第四種方法。mysql> explain select k,max(id) from tbl group by k G
*************************** 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: Using index for group-by
1 row in set, 1 warning (0.00 sec)
mysql> select k,max(id) from tbl group by k;
+---+---------+
| k | max(id) |
+---+---------+
| 0 | 2340920 |
| 1 | 2340916 |
| 2 | 2340932 |
| 3 | 2340928 |
| 4 | 2340924 |
+---+---------+
5 rows in set (0.00 sec)
此方法僅適用於非常特殊的聚合函式:MIN() 和 MAX()。這些並不需要遍歷組中的所有行來計算值。他們可以直接跳轉到組中的最小或最大組值(如果有這樣的索引)。如果索引僅建立在 (K) 列上,如何找到每個組的 MAX(ID) 值?這是一個 InnoDB 表。記住 InnoDB 表有效地將 PRIMARY KEY 附加到所有索引。(K) 變為 (K,ID),允許我們對此查詢使用 Skip-Scan 最佳化。僅當每個組有大量行時才會啟用此最佳化。否則,MySQL 更傾向於使用更傳統的方法來執行此查詢(如方法#1中詳述的索引有序 GROUP BY)。雖然我們使用 MIN() / MAX() 聚合函式,但其他最佳化也適用於它們。例如,如果您有一個沒有 GROUP BY 的聚合函式(實際上所有表都有一個組),MySQL 在統計分析階段從索引中獲取這些值,並避免在執行階段完全讀取表: mysql> explain select max(k) from tbl G *************************** 1. row *************************** id: 1 select_type: SIMPLE table: NULL partitions: NULL type: NULL possible_keys: NULL key: NULL key_len: NULL ref: NULL rows: NULL filtered: NULL Extra: Select tables optimized away 1 row in set, 1 warning (0.00 sec)過濾和分組
我們已經研究了 MySQL 執行 GROUP BY 的四種方式。為簡單起見,我在整個表上使用了 GROUP BY,沒有應用過濾。當您有 WHERE 子句時,相同的概念適用: mysql> explain select g, sum(g) s from tbl where k>4 group by g order by NULL limit 5 G *************************** 1. row *************************** id: 1 select_type: SIMPLE table: tbl partitions: NULL type: range possible_keys: k key: k key_len: 4 ref: NULL rows: 1 filtered: 100.00 Extra: Using index condition; Using temporary 1 row in set, 1 warning (0.00 sec)對於這種情況,我們使用K列上的範圍進行資料過濾/查詢,並在有臨時表時執行 GROUP BY。在某些情況下,方法不會發生衝突。但是,在其他情況下,我們必須選擇使用 GROUP BY 的一個索引或其他索引進行過濾:mysql> alter table tbl add key(g);
Query OK, 0 rows affected (4.17 sec)
Records: 0 Duplicates: 0 Warnings: 0
mysql> explain select g, sum(g) s from tbl where k>1 group by g limit 5 G
*************************** 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: Using where
1 row in set, 1 warning (0.00 sec)
mysql> explain select g, sum(g) s from tbl where k>4 group by g limit 5 G
*************************** 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: Using index condition; Using temporary; Using filesort
1 row in set, 1 warning (0.00 sec)
根據此查詢中使用的特定常量,我們可以看到我們對 GROUP BY 使用索引順序掃描(並從索引中“放棄”以解析 WHERE 子句),或者使用索引來解析 WHERE 子句(但使用臨時表來解析 GROUP BY)。根據我的經驗,這就是 MySQL GROUP BY 並不總是做出正確選擇的地方。您可能需要使用 FORCE INDEX 以您希望的方式執行查詢。
回覆列表
讓group by 使用索引而不建立臨時表,使用索引的前提條件是:所有GROUP BY列引用同一索引的屬性,並且索引按順序儲存其關鍵字(B-樹索引,不是HASH索引)至於DISTINCT 和GROUP BY哪個效率更高?理論上 DISTINCT操作只需要找出所有不同的值就可以了。而GROUP BY操作還要為其他聚集函式進行準備工作。從這一點上將,GROUP BY操作做的工作應該比DISTINCT所做的工作要多一些。但是實際上,DISTINCT操作,它會讀取了所有記錄;GROUP BY需要讀取的記錄數量與分組的組數量一樣多,比實際存在的記錄數目要少很多。