MYSQL ORDER BY Optimization

 ORDER BY Optimization

       某些情况下，MYSQL可以使用index排序而避免额外的sorting.

       即使order by语句列不能准确的匹配index,只要没有index中（不在order by的列）在where语句以常量形式出现。（最左前缀）

SELECT * FROM t1
  ORDER BY key_part1,key_part2,... ;

SELECT * FROM t1
  WHERE key_part1 = constant
  ORDER BY key_part2;

SELECT * FROM t1
  ORDER BY key_part1 DESC, key_part2 DESC;

SELECT * FROM t1
  WHERE key_part1 = 1
  ORDER BY key_part1 DESC, key_part2 DESC;

SELECT * FROM t1
  WHERE key_part1 > constant
  ORDER BY key_part1 ASC;

SELECT * FROM t1
  WHERE key_part1 < constant
  ORDER BY key_part1 DESC;

SELECT * FROM t1
  WHERE key_part1 = constant1 AND key_part2 > constant2
  ORDER BY key_part2;

       某些情况下，依旧使用Index来查找匹配where子句的行，但MYSQL不用index来解决order by：

      1：order by子句中使用不同indexes：

SELECT * FROM t1 ORDER BY key1, key2;

      2：使用不连续的index部分（联合key的非最左前缀）

SELECT * FROM t1 WHERE key2=constant ORDER BY key_part2;

      3：混合使用asc 和desc:

SELECT * FROM t1 ORDER BY key_part1 DESC, key_part2 ASC;

      4:获得数据行的index(where子句中)和Order by 中使用的不一样：

SELECT * FROM t1 WHERE key2=constant ORDER BY key1;

      5：order by子句中使用index的表达式：

SELECT * FROM t1 ORDER BY ABS(key);
SELECT * FROM t1 ORDER BY -key;

      6：join操作时，order by子句的列不全是第一个非 const表;

      7: 不同的order by,group by表达式：

      8：只对order by子句列的前缀加index,这种情况下index不能解决sort. e.g : order by列包含一个char(20)类型，但是只对前10bytes加index；

      9：table index无序,the index of hash（memory表）；

 

    一个index是否排序可用可能受列的别名影响，表t1列 a 为索引：

可以利用index来排序：

SELECT a FROM t1 ORDER BY a;

不能：

SELECT ABS(a) AS a FROM t1 ORDER BY a;

        该语句中，order by引用的是列a, select子句的列名也是a, 但是他是别名，引用的是abs(a);

        下面的语句中，order by引用列名和select list中的列名不一样，但是select用到a,index sort可以使用（该语句的排序结果和以abs(a)排序的完全不一样）

SELECT ABS(a) AS b FROM t1 ORDER BY a;

        默认的，mysql对所有的组col1,col2（group by col1,col2）排序，如果一个查询包含group by但是想避免sort的负载，可以压制排序通过order by null.

INSERT INTO foo
SELECT a, COUNT(*) FROM bar GROUP BY a ORDER BY NULL;

       依赖隐式的group by 排序在mysql5.6中被舍弃。更可取的是使用准确的order by子句。

       MYSQL有两种filesort算法来获得结果。原始的方法只使用order by中的列list. 改写过的方法不仅仅使用order by子句中的列，而是查询中所使用到的列。

       优化器选择哪个filesort算法？正常情况下使用第二种(BLOB TEXT等大对象列外)，两种算法，都使用到sort_buffer_size系统变量：

       原始的filesort算法工作：

       1：根据key值或者scan all the table(where条件)读取所有满足条件的行，跳过不满足where子句的行。

       2：对于每一行，存储（key value, row id）对在sort buffer中。

       3： 如果所有上述对能全部放在sort buffer中，临时文件不会被创建，否则，当sort buffer满时，内存中执行quicksort并且把结果写进临时文件中，保存一个指针执行这个 sorted block.

       4:重复执行上述的过程，直到所有的行都被读取。

       5：执行一个多路归并排序，把第一个文件的block转移到另外一个临时文件中。重复执行，直到第一个文件内容全部在第二个文件中。

       6：一直merge buffer直到剩下2个block

       7：最后一次merge，只写入rowid到结果表

       8.根据排序结果中的rowid顺序读取数据。（手册中还提到了一个优化方案，但是我不认为能起到优化作用）。

     

      该filesort中出现两次读取操作，第一次在where子句判断，另外一次是在拍完value pairs后。然而即使第一次访问是连续读取（e.g. scan all the table）,但是第二次他们是随机访问（尽管key排过序了，但是行位置没有~！）；

       

      第二种filesort算法：（避开二次读，不是记录rowID,而是记录查询所使用的引用列）

     1：读取满足where子句的所有行

     2：对于每一行，元组记录key value和查询所引用到的列

     3：当buffer满时，排序并写入临时文件

     4：merge sort所有的临时文件，检索有序的行数据，直接从排过序的元组中读取需要的列而不是两次访问基表

   

     

      修改后的方法，列长于原来的方法。很有可能会产生大量IO，让排序变得很慢。为了避免这个问题，优化器会所有读取列的长度小于max_length_for_sort_data系统变量，才会选择修改后的算法。

      当filesort完成，explain输出中extra会有using filesort，优化器跟踪输出中filesort_summary块：

"filesort_summary": {
  "rows": 100,
  "examined_rows": 100,
  "number_of_tmp_files": 0,
  "sort_buffer_size": 25192,
  "sort_mode": "<sort_key, additional_fields>"
}

    其中sort mode就说了算法：

    <sort_key,rowid>表示原始的算法

    <sort_key,addtitional_filed>表示是修改后的算法

    为了提高排序速度，可以检查是否可以使用索引，如果不能使用：

       1.增加sort_buffer_size的大小

       2.增加read_rnd_buffer_size的大小

       3.通过表设计减少空间占用

       4.修改tmpdir目录指向专用文件系统

       如果order by没有使用索引，但是有limit子句，那么优化器可能可以避免合并临时文件，直接在内存中排序