| 代码见：/sql/sql_select.cc，test_if_order_by_key()和/sql/sql_select.cc，test_if_skip_sort_order()。
ORDER BY Optimization，描述了SORT排序过程的内容机制，在这里不重复解释。但恳请你一定要阅读，因为它描述了缓冲和快速排序机制的操作。
GROUP BY和相关的条件
这里描述了GROUP BY和相关条件（HAVING，COUNT()，MAX()，MIN()，SUM()，AVG()，DISTINCT()）的主要优化。
GROUP BY会使用索，如果一个索引存在的话。
GROUP BY会用排序，如果没有索引存在。优化器可能选择使用HASH表排序。
GROUP BY x ORDER BY x的情况，优化器会因为GROUP BY会以 x 的排序，而认为ORDER BY是不需要的。
优化器包含了为转移特定HAVING条件的WHERE语句中的代码。然而，此代码在编写时是不生效的。源代码见：/sql/sql_select.cc，JOIN::optimize()，在#ifdef HAVE_REF_TO_FIELDS之后。
如果表句柄（handler）有个有效的快速行总数（row-count），那么这个查询：
SELECT COUNT(*) FROM Table1;
不必扫描所有行，就能得到行总数值。这只对MyISAM表是正确的，但不适合InnoDB表。另外这个查询
SELECT COUNT(column1) FROM Table1;
不会有同样的优化，除非column1被定义为NOT NULL。
MAX()和MIN()新的优化方法。例：
SELECT MAX(column1)
FROM Table1
WHERE column1 < ''a'';
如果column1被索引了，就很容易找到最大值通过查询索引中的''a''值并且在这之前返回索引键。
优化对如下形式的查询，进行语句转化：
SELECT DISTINCT column1 FROM Table1;
成：
SELECT column1 FROM Table1 GROUP BY column1;
当且仅当这两个条件都是正确：
* GROUP BY能通过索引来未完成。这暗示了只有一个表在FROM语句中且没有WHERE语句。
* 没有LIMIT语句。
因为DISTINCT语句并不总是被转化成GROUP BY，不要期望含有DISTINCT查询语句总会有被排序的结果集。然而，你能依赖GROUP BY优化规则，除非查询包括ORDER BY NULL。
三。其它优化
这部分，讨论其它更特别的优化方法。
1. ref和eq_ref的NULLs值过滤访问
这部分讨论ref和eq_ref联接类型的NULLs值过滤优化方法。
前期（early）NULLs值过滤
假设我们有个联接顺序如下：
..., tblX, ..., tblY, ...
更深入假设，表tblY通过ref或eq_ref 联合类型被访问：
tblY.key_column = tblX.column
或者，使用多个键部分的r
|
