<b>MySQL ORDER BY 的实现解析</b>[MySQL防范]

下面将通过实例解析两种排序实现方法及实现图解:
假定有 Table A 和 B 两个表构造辨别以下:
sky@localhost : example 01:48:21> show create table AG
*************************** 1. row ***************************
Table: A
Create Table: CREATE TABLE `A` (
`c1` int(11) NOT NULL default ‘0′,
`c2` char(2) default NULL,
`c3` varchar(16) default NULL,
`c4` datetime default NULL,
PRIMARY KEY (`c1`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8

sky@localhost : example 01:48:32> show create table BG
*************************** 1. row ***************************
Table: B
Create Table: CREATE TABLE `B` (
`c1` int(11) NOT NULL default ‘0′,
`c2` char(2) default NULL,
`c3` varchar(16) default NULL,
PRIMARY KEY (`c1`),
KEY `B_c2_ind` (`c2`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8

1、操纵有序索引举行排序,实际上就是当我们 Query 的 ORDER BY 条件和 Query 的履行筹划中所操纵的 Index 的索引键（或前面几个索引键）完好一致,且索引拜候方法为 rang、 ref 大概 index 的时刻,MySQL 可以操纵索引次序而直接获得已经排好序的数据.这种方法的 ORDER BY 基本上可以说是最优的排序方法了,因为 MySQL 不需求举行实际的排序操作.

假定我们在Table A 和 B 上履行以下SQL:
sky@localhost : example 01:44:28> EXPLAIN SELECT A.* FROM A,B
-> WHERE A.c1 > 2 AND A.c2 < 5 AND A.c2 = B.c2 ORDER BY A.c1G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: A
type: range
possible_keys: PRIMARY
key: PRIMARY
key_len: 4
ref: NULL
rows: 3
Extra: Using where
*************************** 2. row ***************************
id: 1
select_type: SIMPLE
table: B
type: ref
possible_keys: B_c2_ind
key: B_c2_ind
key_len: 7
ref: example.A.c2
rows: 2
Extra: Using where; Using index

我们通过履行筹划可以看出,MySQL实际上并没有举行实际的排序操作,实际上其整个履行历程以下图所示:

2、通过呼应的排序算法,将获得的数据在内存中举行排序方法,MySQL 比需求将数据在内存中举行排序,所利用的内存区域也就是我们通过 sort_buffer_size 系统变量所设置的排序区.这个排序区是每个 Thread 独享的,所以说大概在同一时刻在 MySQL 中大概存在多个 sort buffer 内存区域.

第二种方法在 MySQL Query Optimizer 所给出的履行筹划（通过 EXPLAIN 号令查看）中被称为 filesort.在这种方法中,主如果由于没有可以操纵的有序索引获得有序的数据,MySQL只能通过将获得的数据在内存中举行排序然后再将数据返回给客户端.在 MySQL 中 filesort 的实现算法实际上是有两种的,一种是首先按照呼应的条件取出呼应的排序字段和可以直接定位行数据的行指针信息,然后在 sort buffer 中举行排序.别的一种是一次性取出满意条件行的全部字段,然后在 sort buffer 中举行排序.

在 MySQL4.1 版本之前只有第一种排序算法,第二种算法是从 MySQL4.1开始的改良算法,主要目的是为了削减第一次算法中需求两次拜候表数据的 IO 操作,将两次变成了一次,但呼应也会耗用更多的 sort buffer 空间.当然,MySQL4.1开始的今后全部版本同时也支持第一种算法,MySQL 主要通过对比我们所设定的系统参数 max_length_for_sort_data 的大小和 Query 语句所取出的字段范例大小总和来断定需求利用哪一种排序算法.假如 max_length_for_sort_data 更大,则利用第二种优化后的算法,反之利用第一种算法.所以假如但愿 ORDER BY 操作的效率尽大概的高,一定要主义 max_length_for_sort_data 参数的设置.曾经就有同事的数据库呈现大量的排序等候,造成系统负载很高,并且呼应时间变得很长,最后查出恰是因为 MySQL 利用了传统的第一种排序算法而招致,在加大了 max_length_for_sort_data 参数值之后,系统负载即刻得到了大的减缓,呼应也快了很多.

我们再看看 MySQL 需求利用 filesort 实现排序的实例.

假定我们改变一下我们的 Query,换成通过A.c2来排序,再看看情形:
sky@localhost : example 01:54:23> EXPLAIN SELECT A.* FROM A,B
-> WHERE A.c1 > 2 AND A.c2 < 5 AND A.c2 = B.c2 ORDER BY A.c2G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: A
type: range
possible_keys: PRIMARY
key: PRIMARY
key_len: 4
ref: NULL
rows: 3
Extra: Using where; Using filesort
*************************** 2. row ***************************
id: 1
select_type: SIMPLE
table: B
type: ref
possible_keys: B_c2_ind
key: B_c2_ind
key_len: 7
ref: example.A.c2
rows: 2
Extra: Using where; Using index

MySQL 从 Table A 中取出了符合条件的数据,由于获得的数据并不满意 ORDER BY 条件,所以 MySQL 举行了 filesort 操作,其整个履行历程以下图所示:

在 MySQL 中,filesort 操作还有一个对比奇特的限制,那就是其数据源必须是根源于一个 Table,所以,假如我们的排序数据假如是两个（大概更多个） Table 通过 Join所得出的,那么 MySQL 必须通过先成立一个暂时表（Temporary Table）,然后再将此暂时表的数据举行排序,以下例所示:

sky@localhost : example 02:46:15> explain select A.* from A,B
-> where A.c1 > 2 and A.c2 < 5 and A.c2 = B.c2 order by B.c3G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: A
type: range
possible_keys: PRIMARY
key: PRIMARY
key_len: 4
ref: NULL
rows: 3
Extra: Using where; Using temporary; Using filesort
*************************** 2. row ***************************
id: 1
select_type: SIMPLE
table: B
type: ref
possible_keys: B_c2_ind
key: B_c2_ind
key_len: 7
ref: example.A.c2
rows: 2
Extra: Using where

这个履行筹划的输出还是有点奇特的,不知道为什么,MySQL Query Optimizer 将 "Using temporary" 历程显示在第一行对 Table A 的操作中,莫非只是为让履行筹划的输出少一行?

实际履行历程应当是以下图所示: