读《MySQL性能调优与架构设计》笔记之ORDER BY，GROUP BY 和DI STI NCT 优化

深碍√TFBOYSˉ_ 2022-08-06 11:15 133阅读 0赞

## 1.1. ORDER BY 的实现与优化 ##

在MySQL 中，ORDER BY 的实现有如下两种类型：

◆ 一种是通过有序索引而直接取得有序的数据，这样不用进行任何排序操作即可得到满足客户端要求的有序数据返回给客户端；

◆ 另外一种则需要通过MySQL 的排序算法将存储引擎中返回的数据进行排序然后再将排序后的数据返回给客户端。

下面我们就针对这两种实现方式做一个简单的分析。首先分析一下第一种不用排序的实现方式。同样还是通过示例来说话吧：

> EXPLAIN

\-> SELECT m.id,m.subject,c.content

\-> FROM group\_message m,group\_message\_content c

\-> WHERE m.group\_id = 1 AND m.id = c.group\_msg\_id

\-> ORDER BY m.user\_id\\G

\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* 1. row \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*

id: 1

select\_type: SIMPLE

table: m

type: ref

possible\_keys: PRIMARY,idx\_group\_message\_gid\_uid

key: idx\_group\_message\_gid\_uid

key\_len: 4

ref: const

rows: 4

Extra: Using where

\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* 2. row \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*

id: 1

select\_type: SIMPLE

table: c

type: ref

possible\_keys: group\_message\_content\_msg\_id

key: group\_message\_content\_msg\_id

key\_len: 4

ref: example.m.id

rows: 11

Extra:

看看上面的这个Query 语句，明明有ORDER BY user\_id，为什么在执行计划中却没有排序操作呢？其实这里正是因为MySQL Query Optimizer 选择了一个有序的索引来进行访问表中的数据（idx\_group\_message\_gid\_uid），这样，我们通过group\_id 的条件得到的数据已经是按照group\_id和user\_id 进行排序的了。而虽然我们的排序条件仅仅只有一个user\_id，但是我们的WHERE 条件决定了返回数据的group\_id 全部一样，也就是说不管有没有根据group\_id 来进行排序，返回的结果集都是完全一样的。我们可以通过如下的图示来描述整个执行过程：

![20150118184343234][]

图中的Table A 和Table B 分别为上面Query 中的group\_message 和gruop\_message\_content这两个表。这种利用索引实现数据排序的方法是MySQL 中实现结果集排序的最佳做法，可以完全避免因为排序计算所带来的资源消耗。所以，在我们优化Query 语句中的ORDER BY 的时候，尽可能利用已有的索引来避免实际的排序计算，可以很大幅度的提升ORDER BY 操作的性能。在有些Query 的优化过程中，即使为了避免实际的排序操作而调整索引字段的顺序，甚至是增加索引字段也是值得的。当然，在调整索引之前，同时还需要评估调整该索引对其他Query 所带来的影响，平衡整体得失。

如果没有索引利用的时候，MySQL 又如何来实现排序呢？这时候MySQL 无法避免需要通过相关的排序算法来将存储引擎返回的数据进行排序运算了。下面我们再针对这种实现方式进行相应的分析。

在MySQL 第二种排序实现方式中，必须进行相应的排序算法来实现数据的排序。MySQL 目前可以通过两种算法来实现数据的排序操作。

1. 取出满足过滤条件的用于排序条件的字段以及可以直接定位到行数据的行指针信息，在Sort Buffer 中进行实际的排序操作，然后利用排好序之后的数据根据行指针信息返回表中取得客户端请求的其他字段的数据，再返回给客户端；

2. 根据过滤条件一次取出排序字段以及客户端请求的所有其他字段的数据，并将不需要排序的字段存放在一块内存区域中，然后在Sort Buffer 中将排序字段和行指针信息进行排序，最后再利用排序后的行指针与存放在内存区域中和其他字段一起的行指针信息进行匹配合并结果集，再按照顺序返回给客户端。

上面第一种排序算法是MySQL 一直以来就有的排序算法，而第二种则是从MySQL4.1 版本才开始增加的改进版排序算法。第二种算法与第一种相比较，主要优势就是减少了数据的二次访问。在排序之后不需要再一次回到表中取数据，节省了IO 操作。当然，第二种算法会消耗更多的内存，正是一种典型的通过内存空间换取时间的优化方式。下面我们同样通过一个实例来看看当MySQL 不得不使用排序算法的时候的执行计划，仅仅只是更改一下排序字段：

> explain

\-> select m.id,m.subject,c.content

\-> FROM group\_message m,group\_message\_content c

\-> WHERE m.group\_id = 1 AND m.id = c.group\_msg\_id

\-> ORDER BY m.subject\\G

\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* 1. row \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*

id: 1

select\_type: SIMPLE

table: m

type: ref

possible\_keys: PRIMARY,idx\_group\_message\_gid\_uid

key: idx\_group\_message\_gid\_uid

key\_len: 4

ref: const

rows: 4

Extra: Using where; Using filesort

\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* 2. row \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*

id: 1

select\_type: SIMPLE

table: c

type: ref

possible\_keys: group\_message\_content\_msg\_id

key: group\_message\_content\_msg\_id

key\_len: 4

ref: example.m.id

rows: 11

Extra:

Extra 信息中，多了一个“Using filesort”的信息，实际上这就是MySQL Query Optimizer 在告诉我们，他需要进行排序操作才能按照客户端的要求返回有序的数据。执行图示如下：

![20150118184414828][]

这里我们看到了，MySQL 在取得第一个表的数据之后，先根据排序条件将数据进行了一次filesort，也就是排序操作。然后再利用排序后的结果集作为驱动结果集来通过Nested Loop Join 访问第二个表。当然，大家不要误解，这个filesort 并不是说通过磁盘文件进行排序，仅仅只是告诉我们进行了一个排序操作。

上面，我们看到了排序结果集来源仅仅只是单个表的比较简单的filesort 操作。而在我们实际应用中，很多时候我们的业务要求可能并不是这样，可能需要排序的字段同时存在于两个表中，或者MySQL 在经过一次Join 之后才进行排序操作。这样的排序在MySQL 中并不能简单的里利用Sort Buffer 进行排序，而是必须先通过一个临时表将之前Join 的结果集存放入临时表之后在将临时表的数据取到Sort Buffer 中进行操作。下面我们通过再次更改排序要求来示例这样的执行计划，当我们选择通过group\_message\_content 表上面的content字段来进行排序之后：

> explain

\-> select m.id,m.subject,c.content

\-> FROM group\_message m,group\_message\_content c

\-> WHERE m.group\_id = 1 AND m.id = c.group\_msg\_id

\-> ORDER BY c.content\\G

\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* 1. row \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*

id: 1

select\_type: SIMPLE

table: m

type: ref

possible\_keys: PRIMARY,idx\_group\_message\_gid\_uid

key: idx\_group\_message\_gid\_uid

key\_len: 4

ref: const

rows: 4

Extra: Using temporary; Using filesort

\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* 2. row \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*

id: 1

select\_type: SIMPLE

table: c

type: ref

possible\_keys: group\_message\_content\_msg\_id

key: group\_message\_content\_msg\_id

key\_len: 4

ref: example.m.id

rows: 11

Extra:

这时候的执行计划中出现了“Using temporary”，正是因为我们的排序操作需要在两个表Join 之后才能进行，下图展示了这个Query 的执行过程：

![20150118184437437][]

首先是Table A 和Table B 进行Join，然后结果集进入临时表，再进行filesort，最后得到有序的结果集数据返回给客户端。当我们无法避免排序操作的时候，我们又该如何来优化呢？

1. 加大max\_length\_for\_sort\_data参数的设置；

在MySQL 中，决定使用第一种老式的排序算法还是新的改进算法的依据是通过参数max\_length\_for\_sort\_data来决定的。当我们所有返回字段的最大长度小于这个参数值的时候，MySQL 就会选择改进后的排序算法，反之，则选择老式的算法。所以，如果我们有充足的内存让MySQL 存放需要返回的非排序字段的时候，可以加大这个参数的值来让MySQL 选择使用改进版的排序算法。

2. 去掉不必要的返回字段；

当我们的内存并不是很充裕的时候，我们不能简单的通过强行加大上面的参数来强迫MySQL 去使用改进版的排序算法，因为如果那样可能会造成MySQL 不得不将数据分成很多段然后进行排序，这样的结果可能会得不偿失。在这种情况下，我们就需要去掉不必要的返回字段，让我们的返回结果长度适应max\_length\_for\_sort\_data 参数的限制。

3. 增大sort\_buffer\_size 参数设置；

增大sort\_buffer\_size 并不是为了让MySQL 可以选择改进版的排序算法，而是为了让MySQL可以尽量减少在排序过程中对需要排序的数据进行分段，因为这样会造成MySQL 不得不使用临时表来进行交换排序。

## 1.2. GROUP BY 的实现与优化 ##

由于GROUP BY 实际上也同样需要进行排序操作，而且与ORDER BY 相比，GROUP BY 主要只是多了排序之后的分组操作。当然，如果在分组的时候还使用了其他的一些聚合函数，那么还需要一些聚合函数的计算。所以，在GROUP BY 的实现过程中，与ORDER BY 一样也可以利用到索引。

在MySQL 中，GROUP BY 的实现同样有多种（三种）方式，其中有两种方式会利用现有的索引信息来完成GROUP BY，另外一种为完全无法使用索引的场景下使用。下面我们分别针对这三种实现方式做一个分析。

1. 使用松散（Loose）索引扫描实现GROUP BY

何谓松散索引扫描实现GROUP BY 呢？实际上就是当MySQL 完全利用索引扫描来实现GROUP BY的时候，并不需要扫描所有满足条件的索引键即可完成操作得出结果。

下面我们通过一个示例来描述松散索引扫描实现GROUP BY，在示例之前我们需要首先调整一下group\_message 表的索引，将gmt\_create 字段添加到group\_id 和user\_id 字段的索引中：

> create index idx\_gid\_uid\_gc

\-> on group\_message(group\_id,user\_id,gmt\_create);

> drop index idx\_group\_message\_gid\_uid on group\_message;

然后再看如下Query 的执行计划：

> EXPLAIN

\-> SELECT user\_id,max(gmt\_create)

\-> FROM group\_message

\-> WHERE group\_id < 10

\-> GROUP BY group\_id,user\_id\\G

\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* 1. row \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*

id: 1

select\_type: SIMPLE

table: group\_message

type: range

possible\_keys: idx\_gid\_uid\_gc

key: idx\_gid\_uid\_gc

key\_len: 8

ref: NULL

rows: 4

Extra: Using where; Using index for group-by

1 row in set (0.00 sec)

我们看到在执行计划的Extra 信息中有信息显示“Using index for group-by”，实际上这就是告诉我们，MySQL Query Optimizer 通过使用松散索引扫描来实现了我们所需要的GROUP BY 操作。

下面这张图片描绘了扫描过程的大概实现：

![20150118184509296][]

要利用到松散索引扫描实现GROUP BY，需要至少满足以下几个条件：

◆ GROUP BY 条件字段必须在同一个索引中最前面的连续位置；

◆ 在使用GROUP BY 的同时，只能使用MAX 和MIN 这两个聚合函数；

◆ 如果引用到了该索引中GROUP BY 条件之外的字段条件的时候，必须以常量形式存在；

2. 使用紧凑（Tight）索引扫描实现GROUP BY

........

3. 使用临时表实现GROUP BY

MySQL 在进行GROUP BY 操作的时候要想利用索引，必须满足GROUP BY 的字段必须同时存放于同一个索引中，且该索引是一个有序索引（如Hash 索引就不能满足要求）。而且，并不只是如此，是否能够利用索引来实现GROUP BY 还与使用的聚合函数也有关系。

前面两种GROUP BY 的实现方式都是在有可以利用的索引的时候使用的，当MySQL Query Optimizer无法找到合适的索引可以利用的时候，就不得不先读取需要的数据，然后通过临时表来完成GROUP BY 操作。

> EXPLAIN

\-> SELECT max(gmt\_create)

\-> FROM group\_message

\-> WHERE group\_id > 1 and group\_id < 10

\-> GROUP BY user\_id\\G

\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* 1. row \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*

id: 1

select\_type: SIMPLE

table: group\_message

type: range

possible\_keys: idx\_group\_message\_gid\_uid,idx\_gid\_uid\_gc

key: idx\_gid\_uid\_gc

key\_len: 4

ref: NULL

rows: 32

Extra: Using where; Using index; Using temporary; Using filesort

这次的执行计划非常明显的告诉我们MySQL 通过索引找到了我们需要的数据，然后创建了临时表，又进行了排序操作，才得到我们需要的GROUP BY 结果。整个执行过程大概如下图所展示：

![20150118184552602][]

当MySQL Query Optimizer 发现仅仅通过索引扫描并不能直接得到GROUP BY 的结果之后，他就不得不选择通过使用临时表然后再排序的方式来实现GROUP BY 了。在这样示例中即是这样的情况。group\_id 并不是一个常量条件，而是一个范围，而且GROUP BY字段为user\_id。所以MySQL 无法根据索引的顺序来帮助GROUP BY 的实现，只能先通过索引范围扫描得到需要的数据，然后将数据存入临时表，然后再进行排序和分组操作来完成GROUP BY。

对于上面三种MySQL 处理GROUP BY 的方式，我们可以针对性的得出如下两种优化思路：

1. 尽可能让MySQL 可以利用索引来完成GROUP BY 操作，当然最好是松散索引扫描的方式最佳。

在系统允许的情况下，我们可以通过调整索引或者调整Query 这两种方式来达到目的；

2. 当无法使用索引完成GROUP BY 的时候，由于要使用到临时表且需要filesort，所以我们必须要有足够的sort\_buffer\_size 来供MySQL 排序的时候使用，而且尽量不要进行大结果集的GROUP BY 操作，因为如果超出系统设置的临时表大小的时候会出现将临时表数据copy 到磁盘上面再进行操作，这时候的排序分组操作性能将是成数量级的下降；

至于如何利用好这两种思路，还需要大家在自己的实际应用场景中不断的尝试并测试效果，最终才能得到较佳的方案。此外，在优化GROUP BY 的时候还有一个小技巧可以让我们在有些无法利用到索引的情况下避免filesort 操作，也就是在整个语句最后添加一个以null 排序（ORDER BY null）的子句。

order by null用途是强制对查询结果禁用排序。通过explain检查查询语句时候，如果看到Extra列中有Using filesort，这是对性能有一定影响的，特别是使用了group by时，就算你没有显示的指定order by，mysql会默认按照分组字段进行排序。某些情况下是没有必要使用排序的，例如在处理表报数据的时候（把原始表数据统计后插入到一个用于报表查询的表），则完全可以可以使用order by null来取消排序。

## 1.3. DISTINCT 的实现与优化 ##

DISTINCT 实际上和GROUP BY 的操作非常相似，只不过是在GROUP BY 之后的每组中只取出一条记录而已。所以，DISTINCT 的实现和GROUP BY 的实现也基本差不多，没有太大的区别。同样可以通过松散索引扫描或者是紧凑索引扫描来实现，当然，在无法仅仅使用索引即能完成DISTINCT 的时候，MySQL只能通过临时表来完成。但是，和GROUP BY 有一点差别的是，DISTINCT 并不需要进行排序。也就是说，在仅仅只是DISTINCT 操作的Query 如果无法仅仅利用索引完成操作的时候，MySQL 会利用临时表来做一次数据的“缓存”，但是不会对临时表中的数据进行filesort 操作。当然，如果我们在进行DISTINCT 的时候还使用了GROUP BY 并进行了分组，并使用了类似于MAX 之类的聚合函数操作，就无法避免filesort 了。

下面我们就通过几个简单的Query 示例来展示一下DISTINCT 的实现。

首先看看通过松散索引扫描完成DISTINCT 的操作：

> EXPLAIN SELECT DISTINCT group\_id FROM group\_message\\G

\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* 1. row \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*

id: 1

SELECT\_type: SIMPLE

table: group\_message

type: range

possible\_keys: NULL

key: idx\_gid\_uid\_gc

key\_len: 4

ref: NULL

rows: 10

Extra: Using index for group-by

1 row in set (0.00 sec)

我们可以很清晰的看到，执行计划中的Extra 信息为“Using index for group-by”，这代表什么意思？为什么我没有进行GROUP BY 操作的时候，执行计划中会告诉我这里通过索引进行了GROUP BY 呢？其实这就是于DISTINCT 的实现原理相关的，在实现DISTINCT 的过程中，同样也是需要分组的，然后再从每组数据中取出一条返回给客户端。而这里的Extra 信息就告诉我们，MySQL 利用松散索引扫描就完成了整个操作。当然，如果MySQL Query Optimizer 要是能够做的再人性化一点将这里的信息换成“Using index for distinct”那就更好更容易让人理解了。

2. 我们再来看看通过紧凑索引扫描的示例：

> EXPLAIN SELECT DISTINCT user\_id FROM group\_message

\-> WHERE group\_id = 2\\G

\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* 1. row \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*

id: 1

SELECT\_type: SIMPLE

table: group\_message

type: ref

possible\_keys: idx\_gid\_uid\_gc

key: idx\_gid\_uid\_gc

key\_len: 4

ref: const

rows: 4

Extra: Using WHERE; Using index

1 row in set (0.00 sec)

这里的显示和通过紧凑索引扫描实现GROUP BY 也完全一样。实际上，这个Query 的实现过程中，MySQL 会让存储引擎扫描group\_id = 2 的所有索引键，得出所有的user\_id，然后利用索引的已排序特性，每更换一个user\_id 的索引键值的时候保留一条信息，即可在扫描完所有gruop\_id = 2 的索引键的时候完成整个DISTINCT 操作。

3. 下面我们在看看无法单独使用索引即可完成DISTINCT 的时候会是怎样：

> EXPLAIN SELECT DISTINCT user\_id FROM group\_message

\-> WHERE group\_id > 1 AND group\_id < 10\\G

\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* 1. row \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*

id: 1

SELECT\_type: SIMPLE

table: group\_message

type: range

possible\_keys: idx\_gid\_uid\_gc

key: idx\_gid\_uid\_gc

key\_len: 4

ref: NULL

rows: 32

Extra: Using WHERE; Using index; Using temporary

1 row in set (0.00 sec)

当MySQL 无法仅仅依赖索引即可完成DISTINCT 操作的时候，就不得不使用临时表来进行相应的操作了。但是我们可以看到，在MySQL 利用临时表来完成DISTINCT 的时候，和处理GROUP BY 有一点区别，就是少了filesort。实际上，在MySQL 的分组算法中，并不一定非要排序才能完成分组操作的，

这一点在上面的GROUP BY 优化小技巧中我已经提到过了。实际上这里MySQL 正是在没有排序的情况下实现分组最后完成DISTINCT 操作的，所以少了filesort 这个排序操作。

4. 最后再和GROUP BY 结合试试看：

> EXPLAIN SELECT DISTINCT max(user\_id) FROM group\_message

\-> WHERE group\_id > 1 AND group\_id < 10

\-> GROUP BY group\_id\\G

\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* 1. row \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*

id: 1

SELECT\_type: SIMPLE

table: group\_message

type: range

possible\_keys: idx\_gid\_uid\_gc

key: idx\_gid\_uid\_gc

key\_len: 4

ref: NULL

rows: 32

Extra: Using WHERE; Using index; Using temporary; Using filesort

1 row in set (0.00 sec)

最后我们再看一下这个和GROUP BY 一起使用带有聚合函数的示例，和上面第三个示例相比，可以看到已经多了filesort 排序操作了，因为我们使用了MAX 函数的缘故。

对于DISTINCT 的优化，和GROUP BY 基本上一致的思路，关键在于利用好索引，在无法利用索引的时候，确保尽量不要在大结果集上面进行DISTINCT 操作，磁盘上面的IO 操作和内存中的IO 操作性能完全不是一个数量级的差距。

[20150118184343234]: /images/20220806/1c865d2f41554349a5e3878cbcf828ad.png
[20150118184414828]: /images/20220806/fb6e5e4ba07f4c198524e465d5ee0066.png
[20150118184437437]: /images/20220806/31cf9b0fdd264764a2268b922f0076ba.png
[20150118184509296]: /images/20220806/2aa0c091bfa44be995240f857843e814.png
[20150118184552602]: /images/20220806/5c56393c51ca4cb6ba4b66466c49de78.png