是怎样成功的 聊聊 By Order

首先排序性能由 ORDER BY 成功，详细陈列顺序取决于提升器的选用。若提升器以为索引排序更有效率，则经常使用索引排序；反之，则经常使用 filesort（口头方案中额外消息揭示：经常使用 filesort）。但是，索引排序的实用状况有限，且不确定性较高，通常还是会驳回 filesort。

在 filesort 排序中，假设排序的数据较少，可在内存中的 sort_buffer 上成功；否则，需借助暂时文件启动排序。实践排序环节中，假设字段长度较短，可间接在 sort_buffer 中启动全字段排序并前往结果集。若字段长度较长，或许出于空间考量，驳回基于 row_id 的排序，此时会启动二次回表后前往结果集。

索引排序

妇孺皆知，索引具有自然的排序属性，因此在经常使用 ORDER BY 时，若能充沛应用索引，则效率肯定最佳。

MySQL 确实可以基于索引口头 ORDER BY 查问，但是这一环节能否肯定经常使用索引齐全由提升器选择。

CREATE TABLE `t2` (`id` INT(11),`a` varchar(64) NOT NULL,`b` varchar(64) NOT NULL,`c` varchar(64) NOT NULL,`d` varchar(64) NOT NULL,`f` varchar(64) DEFAULT NULL,PRIMARY KEY(id),UNIQUE KEY `f` (`f`),KEY `idx_abc` (`a`,`b`,`c`)KEY `idx_a` (`a`)) ENGINE=InnoDB DEFAULT CHARSET=latin1

假定存在如上所述的表格，在排序环节中或许会出现以下状况（由于提升器的干预，以下结果并不肯定可以 100%复现。依据我的试验，在 MySQL 5.7 环境中是可以的）。

select * from t2 order by a;-- 不走索引，经常使用filesort（前面引见啥是filesort）select * from t2 order by a limit 100;-- 走索引select a,b from t2 order by a limit 100;-- 走索引select a,b,c from t2 order by a;-- 走索引select a,b,c,d from t2 order by a;-- 不走索引，经常使用filesortselect a,b,c,d from t2 where a = "Paidaxing" order by b;-- 走索引select a,b,c,d from t2 where b = "Paidaxing" order by a;-- 不走索引，经常使用filesort

在经常使用索引字段启动排序时，提升器会依据老本评价来选用能否经过索引启动排序。经过我的屡次验证，以下状况中，索引排序的概率较高：

filesort 排序

假设不可经常使用或提升器以为索引排序效率不高，MySQL 将口头 filesort 操作，以读取表中的行并对它们启动排序。

在排序环节中，MySQL 为每个线程调配一块内存用于排序，称为sort_buffer，其大小由sort_buffer_size控制。

依据sort_buffer_size的大小不同，排序操作会出当初不同的

暂时文件排序驳回归并排序算法，首先将须要排序的数据调配到多个暂时文件中，同时启动排序操作，而后将多个排序成功的文件兼并成一个结果集前往给客户端。相关于在内存中的 sort_buffer 排序，磁盘上的暂时文件排序速度较慢。

除了sort_buffer_size参数之外，影响排序算法的另一个关键参数是max_length_for_sort_data。

max_length_for_sort_data是 MySQL 中控制用于排序的行数据的长度的一个参数，自动值为 1024 字节。假设单行长度超越该值，MySQL 就会以为单行太大，因此会驳回 rowid 排序；否则，会启动全字段排序。

全字段排序

所谓全字段排序，行将要查问的一切字段都放入 sort_buffer 中，而后依据排序字段启动排序，排序成功后间接将结果集前往给客户端。

假定咱们有以下查问 SQL：

select a,d,f from t2 where a = "Paidaxing" order by d;--

由于此处触及的字段为 a、d、f 三个，因此将满足 WHERE 条件的一切数据的 a、d、f 字段都放入 sort_buffer 中，而后依据 d 字段在 sort_buffer 中启动排序，排序成功后前往给客户端的大抵环节如下：

以上环节中，假设数据在 sort_buffer 中不可所有寄存，则会经常使用暂时文件，并对暂时文件启动归并排序。

全字段排序的好处在于只要要对原表启动一次性回表查问（每条记载只要回表一次性），排序成功后可以间接前往所需字段，因此效率较高。但其缺陷在于，假设要查问的字段较多，会占用少量 sort_buffer 空间，造成可存储的数据量缩小。当须要排序的数据量增大时，或许会经常使用暂时文件，从而造成全体性能降低。

为防止这个疑问，可以驳回 row_id 排序的形式。

row_id 排序

这个也很好了解，即在构建 sort_buffer 时，不须要将一切要查问的字段都放出来，只要要将排序字段和主键放入即可。

select a,d,f from t2 where a = "Paidaxing" order by d;

比如这个 SQL，只要要将 d 和 id 放入 sort_buffer 中，首先依照 d 启动排序。排序成功后，依据 id 将对应的 a、d、f 几个字段查问出来，而后前往给客户端的大抵环节如下：

以上的第五步，与全字段排序算法相比确实多了一次性回表操作。因此，这种方案的效率必需会稍慢一些。

如何选用

如何选用排序形式？

实践上，row_id 是 MySQL 的一种提升算法，它首先思考经常使用全字段排序。只要在以为字段长渡过长或许影响效率时，才会驳回 row_id 排序形式。此外，假设能够应用 sort_buffer 成功排序，MySQL 就不会经常使用暂时文件。

综上所述，MySQL 在选用排序形式时会优先思考速度、内存和缩小回表次数等起因。