MySql 数据库group by 的用法，order by 嵌套使用。优化问题

不多说，直接看例子。自己动手试试

mysql> select * from tb_clothes;+----+--------+-------+-------+------------+---------+| id | name   | price | total | date       | address |+----+--------+-------+-------+------------+---------+|  1 | 上衣   | 45    | 89    | 2010-01-09 | 河南    ||  2 | 手套   | 7     | 45    | 2010-02-09 | 山东    ||  3 | 上衣   | 56    | 34    | 2010-01-09 | 河南    ||  4 | 手套   | 7     | 12    | 2010-02-09 | 山东    ||  5 | 裤子   | 34    | 56    | 2010-04-12 | 吉林    ||  6 | 毛衣   | 25    | 22    | 2010-08-09 | 吉林    ||  7 | 篮球鞋 | 125   | 23    | 2010-09-12 | 河南    ||  8 | 毛衣   | 25    | 67    | 2010-08-09 | 湖北    ||  9 | 帽子   | 8     | 14    | 2010-10-09 | 吉林    || 10 | 帽子   | 8     | 54    | 2010-10-09 | 陕西    |+----+--------+-------+-------+------------+---------+10 rows in setmysql> select * from tb_clothes group by address;+----+------+-------+-------+------------+---------+| id | name | price | total | date       | address |+----+------+-------+-------+------------+---------+|  5 | 裤子 | 34    | 56    | 2010-04-12 | 吉林    ||  2 | 手套 | 7     | 45    | 2010-02-09 | 山东    ||  1 | 上衣 | 45    | 89    | 2010-01-09 | 河南    ||  8 | 毛衣 | 25    | 67    | 2010-08-09 | 湖北    || 10 | 帽子 | 8     | 54    | 2010-10-09 | 陕西    |+----+------+-------+-------+------------+---------+5 rows in setmysql> select price from tb_clothes group by address;+-------+| price |+-------+| 34    || 7     || 45    || 25    || 8     |+-------+5 rows in setmysql> select sum(price) from tb_clothes group by address;+------------+| sum(price) |+------------+|         67 ||         14 ||        226 ||         25 ||          8 |+------------+5 rows in set

mysql> select sum(price) as SumPrice,address from tb_clothes group by address;+----------+---------+| SumPrice | address |+----------+---------+|       67 | 吉林    ||       14 | 山东    ||      226 | 河南    ||       25 | 湖北    ||        8 | 陕西    |+----------+---------+5 rows in set

与排序的嵌套使用：

mysql> select sum(price) as SumPrice,address from tb_clothes group by address order by SumPrice;+----------+---------+| SumPrice | address |+----------+---------+|        8 | 陕西    ||       14 | 山东    ||       25 | 湖北    ||       67 | 吉林    ||      226 | 河南    |+----------+---------+5 rows in set

优化问题：

复制高手的

满足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能通过顺序读取键(或在键上做排序)来解决，然后计算摘要直到关键字的值改变。在这种情况下，LIMITrow_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次关键字搜索。