SELECT * FROM t1 WHERE key_part1=1
ORDER BY key_part1 DESC, key_part2 DESC;
在某些情况下，MySQL不能使用索引来解决ORDER BY，尽管它仍然使用索引来找到匹配WHERE子句的行。这些情况包括：
· 对不同的关键字使用ORDER BY： ?????????????????SELECT * FROM t1 ORDER BY key1, key2； · 对关键字的非连续元素使用ORDER BY： ?????????????????SELECT * FROM t1 WHERE key2=constant ORDER BY
key_part2；
· 混合ASC和DESC： ?????????????????SELECT * FROM t1 ORDER BY key_part1 DESC, key_part2 ASC；
· 用于查询行的关键字与ORDER BY中所使用的不相同： ?????????????????SELECT * FROM t1 WHERE key2=constant ORDER BY key1； · 你正联接许多表，并且ORDER BY中的列并不是全部来自第1个用于搜索行的非常量表。(这是EXPLAIN输出中的没有const联接类型的第1个表）。
· 有不同的ORDER BY和GROUP BY表达式。
· 使用的表索引的类型不能按顺序保存行。例如，对于HEAP表的HASH索引情况即如此。
通过EXPLAIN SELECT ...ORDER BY，可以检查MySQL是否可以使用索引来解决查询。如果Extra列内有Using filesort，则不能解决查询。参见7.2.1节，“EXPLAIN语法（获取关于SELECT的信息）”。
文件排序优化不仅用于记录排序关键字和行的位置，并且还记录查询需要的列。这样可以避免两次读取行。文件排序算法的工作象这样： 1. 读行匹配WHERE子句的行，如前面所示。
2. 对于每个行，记录构成排序关键字和行位置的一系列值，并且记录查询需要的列。
3. 根据排序关键字排序元组
4. 按排序的顺序检索行，但直接从排序的元组读取需要的列，而不是再一次访问表。
该算法比以前版本的Mysql有很大的改进。
为了避免速度变慢，该优化只用于排序元组中的extra列的总大小不超过
max_length_for_sort_data系统变量值的时候。(将该变量设置得太高的的迹象是将看到硬盘活动太频繁而CPU活动较低）。
如果想要增加ORDER BY的速度，首先看是否可以让MySQL使用索引而不是额外的排序阶段。如果不能，可以尝试下面的策略： · 增加sort_buffer_size变量的大小。
· 增加read_rnd_buffer_size变量的大小。
· 更改tmpdir指向具有大量空闲空间的专用文件系统。该选项接受几个使用round-robin(循环)模式的路径。在Unix中路径应用冒号(‘:’)
区间开，在Windows、NetWare和OS/2中用分号(‘；’)。可以使用该特性将负载均分到几个目录中。注释：路径应为位于不同物理硬盘上的文件系统的目录，而不是同一硬盘的不同的分区。
默认情况下，MySQL排序所有GROUP BY col1，col2，...查询的方法如同在查询中指定ORDER BY col1，col2，...。如果显式包括一个包含相同的列的ORDER BY子句，MySQL可以毫不减速地对它进行优化，尽管仍然进行排序。如果查询包括GROUP BY但你想要避免排序结果的消耗，你可以指定ORDER BY NULL禁止排序。例如： INSERT INTO foo
SELECT a, COUNT(*) FROM bar GROUP BY a ORDER BY NULL;
7.2.13. MySQL如何优化GROUP BY
7.2.13.1. 松散索引扫描 7.2.13.2. 紧凑索引扫描
满足GROUP BY子句的最一般的方法是扫描整个表并创建一个新的临时表，表中每个组的所有行应为连续的，然后使用该临时表来找到组并应用累积函数(如果有)。在某些情况中，MySQL能够做得更好，通过索引访问而不用创建临时表。 为GROUP BY使用索引的最重要的前提条件是 所有GROUP BY列引用同一索引的属性，并且索引按顺序保存其关键字(例如，这是B-树索引，而不是HASH索引)。是否用索引访问来代替临时表的使用还取决于在查询中使用了哪部分索引、为该部分指定的条件，以及选择的累积函数。
有两种方法通过索引访问执行GROUP BY查询，如下面的章节所描述。在第1个方法中，组合操作结合所有范围判断式使用(如果有)。第2个方法首先执行范围扫描，然后组合结果元组。 7.2.13.1. 松散索引扫描
使用索引时最有效的途径是直接搜索组域。通过该访问方法，MySQL使用某些关键字排序的索引类型(例如，B-树)的属性。该属性允许使用 索引中的查找组而不需要考虑满足所有WHERE条件的索引中的所有关键字。既然该访问方法只考虑索引中的关键字的一小部分，它被称为松散索引扫描。如果没有WHERE子句， 松散索引扫描读取的关键字数量与组数量一样多，可以比所有关键字数小得多。如果WHERE子句包含范围判断式(关于range联接类型的讨论参见7.2.1节，
“EXPLAIN语法（获取关于SELECT的信息）”)， 松散索引扫描查找满足范围条件的每个组的第1个关键字，并且再次读取尽可能最少数量的关键字。在下面的条件下是可以的：
· 查询针对一个单表。
· GROUP BY包括索引的第1个连续部分(如果对于GROUP BY，查询有一个DISTINCT子句，则所有显式属性指向索引开头)。
· 只使用累积函数(如果有)MIN()和MAX()，并且它们均指向相同的列。
· 索引的任何其它部分（除了那些来自查询中引用的GROUP BY）必须为常数(也就是说，必须按常量数量来引用它们)，但MIN()或MAX() 函数的参数例外。
此类查询的EXPLAIN输出显示Extra列的Using indexforgroup-by。
下面的查询提供该类的几个例子，假定表t1(c1,c2,c3,c4)有一个索引idx(c1，c2，c3)：
SELECT c1, c2 FROM t1 GROUP BY c1, c2; SELECT DISTINCT c1, c2 FROM t1; SELECT c1, MIN(c2) FROM t1 GROUP BY c1;
SELECT c1, c2 FROM t1 WHERE c1 < const GROUP BY c1, c2;
SELECT MAX(c3), MIN(c3), c1, c2 FROM t1 WHERE c2 > const GROUP BY c1, c2; SELECT c2 FROM t1 WHERE c1 < const GROUP BY c1, c2; SELECT c1, c2 FROM t1 WHERE c3 = const GROUP BY c1, c2； 由于上述原因，不能用该快速选择方法执行下面的查询： 1. 除了MIN()或MAX()，还有其它累积函数，例如：
SELECT c1, SUM(c2) FROM t1 GROUP BY c1;
2. GROUP BY子句中的域不引用索引开头，如下所示：
SELECT c1,c2 FROM t1 GROUP BY c2, c3;
3. 查询引用了GROUP BY部分后面的关键字的一部分，并且没有等于常
量的等式，例如：
SELECT c1,c3 FROM t1 GROUP BY c1, c2；
7.2.13.2. 紧凑索引扫描
紧凑式索引扫描可以为索引扫描或一个范围索引扫描，取决于查询条件。 如果不满足松散索引扫描条件，GROUP BY查询仍然可以不用创建临时表。如果WHERE子句中有范围条件，该方法只读取满足这些条件的关键字。否则，进行索引扫描。该方法读取由WHERE子句定义的每个范围的所有关键字，或没有范围条件式扫描整个索引，我们将它定义为紧凑式索引扫描。请注意对于紧凑式索引扫描，只有找到了满足范围条件的所有关键字后才进行组合操作。
要想让该方法工作，对于引用GROUP BY关键字元素的前面、中间关键字元素的查询中的所有列，有一个常量等式条件即足够了。等式条件中的常量填充了搜索关键字中的“差距”，可以形成完整的索引前缀。这些索引前缀可以用于索引查找。如果需要排序GROUP BY结果，并且能够形成索引前缀的搜索关键字，MySQL
还可以避免额外的排序操作，因为使用有顺序的索引的前缀进行搜索已经按顺序检索到了所有关键字。
上述的第一种方法不适合下面的查询，但第2种索引访问方法可以工作(假定我们已经提及了表t1的索引idx)：
· GROUP BY中有一个差距，但已经由条件c2 = 'a'覆盖。
SELECT c1，c2，c3 FROM t1 WHERE c2 = 'a' GROUP BY c1，c3;
· GROUP BY不以关键字的第1个元素开始，但是有一个条件提供该元素的常量：
SELECT c1，c2，c3 FROM t1 WHERE c1 = 'a' GROUP BY c2，c3;
7.2.14. MySQL如何优化LIMIT
在一些情况中，当你使用LIMIT row_count而不使用HAVING时，MySQL将以不同方式处理查询。
· 如果你用LIMIT只选择一些行，当MySQL选择做完整的表扫描时，它将在一些情况下使用索引。
· 如果你使用LIMIT row_count与ORDER BY，MySQL一旦找到了排序结果的第一个row_count行，将结束排序而不是排序整个表。如果使用索引，将很快。如果必须进行文件排序（filesort），必须选择所有匹配查询没有LIMIT子句的行，并且在确定已经找到第1个row_count行前，必须对它们的大部分进行排序。在任何一种情况下，一旦找到了行，则不需要再排序结果的其它部分，并且MySQL不再进行排序。
· 当结合LIMIT row_count和DISTINCT时，MySQL一旦找到row_count个唯一的行，它将停止。
· 在一些情况下，GROUP BY能通过顺序读取键(或在键上做排序)来解决，然后计算摘要直到关键字的值改变。在这种情况下，LIMIT row_count将不计算任何不必要的GROUP BY值。 · 只要MySQL已经发送了需要的行数到客户，它将放弃查询，除非你正使用SQL_CALC_FOUND_ROWS。
· LIMIT 0将总是快速返回一个空集合。这对检查查询的有效性是有用的。当使用MySQL API时，它也可以用来得到结果列的列类型。(该技巧在MySQL Monitor中不工作，只显示Empty set；应使用SHOW COLUMNS或DESCRIBE）。
· 当服务器使用临时表来进行查询时，使用LIMIT row_count子句来计算需要多少空间。
7.2.15. 如何避免表扫描
EXPLAIN的输出显示了当
MySQL使用表扫描来解决查询时使用的所有类型列。这
通常在如下条件下发生：
· 表很小，扫描表比查找关键字速度快。这对于少于10行并且行较短的表比较普遍。
· 在ON或WHERE子句中没有适用的索引列的约束。
· 正用常量值比较索引列，并且MySQL已经计算到(基于索引树)常数覆盖了表的很大部分并且表扫描将会比较快。参见7.2.4节，“MySQL怎样优化WHERE子句”。
· 你正通过另一个列使用一个低的集的势的关键字(许多行匹配关键字)。在这种情况下，MySQL假设通过使用关键字它可能会进行许多关键字查找，表扫描将会更快。
对于小表，表扫描通常合适。对于大表，尝试下面的技巧以避免优化器错选了表扫描：
· 使用ANALYZE TABLE tbl_name为扫描的表更新关键字分布。参见13.5.2.1节，“ANALYZE TABLE语法”。
· 对扫描的表使用FORCE INDEX告知MySQL，相对于使用给定的索引表扫描将非常耗时。参见13.2.7节，“SELECT语法”。 ?????????????????SELECT * FROM t1, t2 FORCE INDEX (index_for_column)
????????????????? WHERE t1.col_name=t2.col_name；
· 用--max-seeks-for-key=1000选项启动mysqld或使用SET
max_seeks_for_key=1000告知优化器假设关键字扫描不会超过1,000次关键字搜索。参见5.3.3节，“服务器系统变量”。
7.2.16. INSERT语句的速度
插入一个记录需要的时间由下列因素组成，其中的数字表示大约比例：
? ? ? ? ? ?
连接：(3)
发送查询给服务器：(2) 分析查询：(2)
插入记录：（1x记录大小） 插入索引：（1x索引） 关闭：(1)
这不考虑打开表的初始开销，每个并发运行的查询打开。 表的大小以logN (B树)的速度减慢索引的插入。 加快插入的一些方法：
· 如果同时从同一个客户端插入很多行，使用含多个VALUE的INSERT语句同时插入几行。这比使用单行INSERT语句快(在某些情况下快几倍)。如果你正向一个非空表添加数据，可以调节
bulk_insert_buffer_size变量，使数据插入更快。参见5.3.3节，“服务器系统变量”。
· 如果你从不同的客户端插入很多行，能通过INSERT DELAYED语句加快速度。参见13.2.4节，“INSERT语法”。