mysql spj_MySQL查询优化器--非SPJ优化--ORDERBY优化

MySQL提供了两种排序算法操作(即ORDERBY操作，所以理解排序算法有助于理解ORDERBY优化)，在查询执行计划中用“filesort”表示使用了外部文件进行排序。第一种算法是双路排序算法，只利用ORDERBY子句中包括的列对象进行排序(适用于有BLOB、TEXT类型的列对象参与的排序)；第二种算法是单路排序算法，除利用ORDERBY子句中包括的列对象外，还利用查询目标列中的所有列对象进行排序(适用于除BLOB、TEXT类型外的所有的其他类型的排序)。

算法一：双路排序算法的完整实现过程如下：

1)        按索引键或全表扫描的方式，读取所有的元组，不匹配WHERE子句的元组被跳过；第一步需要从存储读入数据，引发I/O操作。

2)        对于每一行，在缓冲区中存储一对值(对值，包括排序关键字和元组指针)。缓冲区的大小是系统变量的sort_buffer_size设定的值。

3)        当缓冲区已满，运行快排算法(快速排序，qsort)对一个块中的数据进行排序，将结果存储在一个临时文件。保存一个指向排序后的块的指针(如果第二步所说的对值都能被缓冲区容纳，则不会创建临时文件)。

4)        重复上述步骤，直到所有的行已经被读取。

5)        执行一个多路归并操作(操作对象是第三步生成的每一个有序的块)汇集到“MERGEBUFF域”，然后存放到在第二个临时文件中。重复操作，直到第一个文件的所有块归并后存入到第二个文件；“MERGEBUFF域”是代码sql_sort.h中定义的宏，值为7。

6)        重复以下操作(第7步和第8步)，直到留下少于“MERGEBUFF2域”标明的块数为止；“MERGEBUFF2域”是代码sql_sort.h中定义的宏，值为15。

7)        在最后一次多路归并操作中，把元组的指针(排序关键字的最后部分)写入到一个结果文件。

8)        在结果文件中，按照排列的顺序使用元组指针读取元组(为了优化这项操作，MySQL读入元组指针进入一个大的块，对块中元组指针进行排序而不是直接对数据排序，然后再用有序的元组指针获取元组到元组缓存，元组缓冲区的大小由read_rnd_buffer_size参数控制)。第8步需要从存储读入数据，引发I/O操作。

算法二：单路排序算法，改进算法一，减少一次I/O，需要增加缓冲区大小容纳更多信息。其具体实现过程如下：

1)        获取与WHERE子句匹配的元组。这一步需要从存储读入数据，引发I/O操作。

2)        对于每一个元组，记录排序键值、行的位置值、查询所需的列。这一步记录更多内容，需要更大缓存，内存存储一条元组的信息的长度比算法一的“对值”大许多，这可能引发排序速度问题(排序对象的长度变长，但是内存有限，所以就需把一次内存排序变为多次，进而影响排序的速度)，为了控制这个问题，MySQL引入一个参数“max_length_for_sort_data”，如果这一步得到的元组长度大于这个值，则不使用算法二。需要MySQL的使用者特别注意的是，在排序中，如果存在“很高磁盘I/O和很低的CPU利用率”的现象，则需要考虑调整“max_length_for_sort_data”的大小以变更换排序算法。

3)        按照排序的键值，对元组(元组是第二步的结果)进行排序。

算法二直接从缓冲区中的排序的元组中获取有序的列信息等(查询的目的对象)，而不是第二次访问该表读取所需的列。相比算法一减少一次I/O。

MySQL支持对于ORDERBY的优化，，下面我们通过具体示例说明。

首先让我们做一些准备工作。创建表，命令如下：

CREATE TABLE t_o1 (a1 INT UNIQUE, b1 INT);

CREATE TABLE t_o2 (a2 INT UNIQUE, b2 INT);

示例1在索引列上进行排序操作，MySQL支持利用索引进行排序优化。

在一个表的索引列上执行排序操作，查询执行计划如下：

mysql> EXPLAIN SELECT * FROM t_o1 ORDER BY a1;

+----+-------------+-------+------+------+----------------+

| id | select_type | table | type | key  | Extra          |

+----+-------------+-------+------+------+----------------+

|  1 | SIMPLE      | t_o1  | ALL  | NULL |Using filesort|

+----+-------------+-------+------+------+----------------+

1 row in set (0.00 sec)

从查询执行计划看，对表进行了全表扫描，并进行了排序操作(Using filesort)。没有利用索引对排序进行优化。

对索引列进行查询，查询执行计划如下：

mysql> EXPLAIN SELECT a1 FROM t_o1 ORDER BY a1;

+----+-------------+-------+-------+------+-------------+

| id | select_type | table | type  | key  | Extra       |

+----+-------------+-------+-------+------+-------------+

|  1 | SIMPLE      | t_o1  | index | a1   | Using index |

+----+-------------+-------+-------+------+-------------+

1 row in set (0.00 sec)

从查询执行计划看，对表进行了索引扫描，利用索引对排序进行优化。对比上一条SQL语句，不同之处在于目标列不同，本条SQL语句的目标列是索引列，不是表的全部字段。这说明MySQL支持利用索引消除排序的技术，但只限于目标列也是索引列。

示例2排序下推，MySQL不支持。在非索引列上执行连接，然后排序，查询执行计划如下：

mysql> EXPLAIN EXTENDED SELECT * FROM t_o1, t_o2 WHERE b1=b2  ORDER BY b1;

+----+-------------+-------+------+-------+----------------------------------------------------+

| id | select_type | table | type |  key  | Extra                                              |

+----+-------------+-------+------+-------+----------------------------------------------------+

|  1 | SIMPLE      | t_o1  | ALL  |  NULL | Using temporary; Using filesort                    |

|  1 | SIMPLE      | t_o2  | ALL  |  NULL | Using where; Using join buffer (Block Nested Loop) |

+----+-------------+-------+------+-------+----------------------------------------------------+

2 rows in set (0.00 sec)

从查询执行计划看，在表t_o1上分别进行了全表扫描后与t_o2表进行了连接，然后用临时文件完成排序。这表明MySQL不可以把排序下推到基表单执行，然后再连接，不支持排序下推优化技术。