mysql5.7官网直译SQL语句优化--DISTINCT,LIMIT优化

1.15DISTINCT Optimization 

DISTINCT和ORDER BY结合多数情况下需要一个临时表。

因为DISTINCT也许用到GROUP BY，了解mysql在order by列上如何工作，或者是having 条件是如何工作的，并且条件不是被选择的列的部分。请看12.19.3的mysql处理group by。

在大多数情况下，一个DISTINCT条件能够被考虑作为一个特别的group by条件。例如，下面的两个查询是等价的：

SELECT DISTINCT c1, c2, c3 FROM t1

WHERE c1 > const;

SELECT c1, c2, c3 FROM t1

WHERE c1 > const GROUP BY c1, c2, c3;

因为这个等价，优化器用于group by查询也能够用于DISTINCT查询。这样，更多关于DISTINCT查询的优化详情，请看8.2.1.14的group by 优化。

当查询条件中有LIMIT ROW_COUNT 和 DISTINCT,mysql会在找到不同的row_count列之后尽快停止。

如果在查询中没有使用来自所有表中的列，那么mysql就会尽量不去扫描那些没有使用的表，在它第一次匹配的时候。在下面的情况下，假设t1会在t2之前使用(你可以通过检查EXPLAIN来查看)，mysql会从t2中找到第一行之后，停止读取t2(对于任意在t1表中特别的行):

SELECT DISTINCT t1.a FROM t1, t2 where t1.a=t2.a;

到此关于DISTINCT优化的介绍就结束了，接下来我们要看的是1.16LIMIT Query Optimization

------------------------------------------

1.16LIMIT Query Optimization

如果你需要一个特别数量的行数从结果集中获取，使用LIMIT条件在查询中，而不是获取整个结果并且再扔掉多余的数据。

mysql有时优化一个查询通过条件 LIMIT row_count条件，并且没有HAVING条件：

>如果你用LIMIT选择少量的行，mysql会用索引查询，而不愿意来全表扫描，在一些情况下。

>如果你查询中用到了order by和limit row_count，mysql会在找到第一个row_count行时停止对结果集排序，而不是排序整个结果集。如果可以通过使用索引来完成排序，那么查询会很快。如果一个文件排序必须发生，所有和查询条件匹配的行需要读取，没有使用limit条件，并且大多数被排序，在找到前row_count行之前。在初始化已经发现的行之后，mysql不会对任何剩下的结果集去排序。

这种行为的表现之一是一个order by查询并且没有limit也许返回不同顺序的行，在之后的部分会有描述，

>如果你将limit row_count和DISTINCT结合，mysql会在找到row_count不同行之后尽快停止。

>在一些情况下，一个group by分组操作可以通过读取有序索引来完成(或者是在索引上完成排序)，然后计算结果直到有索引值改变。在这种情况下，limit row_count没有计算任何没有必要计算的group by值。

> 只要mysql已经发送了需要指定数量的行数据到客户端，它将停止查询除非你用了SQL_CALC_FOUNT_ROWS。在那种情况下，行数量能够通过SELECT FOUND_ROW()来获取。请看12.14的Functions的信息。

>limit 0 会快速的返回空集合。这能够用于检查一个查询可用性。它也能用于获取应用中结果行的类型，使用mysql API使得结果集的元数据可用。通过mysql客户端程序，你能用--column-type_info操作来展示结果列的类型。

>如果服务器用临时表来解析一个查询，他用limit row_count条件计算查询需要多大的空间。

>如果一个索引没有用于order by条件，但是出现了一个limit 条件。优化器也许能够避免使用一个文件合并，并且排序行在内存中通过使用一个内存文件排序操作来完成。更详细的，请看在内存中的文件排序算法。

如果具有相同值的多行数据在order by的列中，服务器将会直接返回这些行数据，而没有任何排序，并且也许完成的完全不同依赖于完整的执行计划。换句话说，这些行的排序是不固定的，依赖于无序的列。

影响执行计划的一个因素是limit,所以一个order by查询使用和不使用limit也许会返回不同顺序的行。思考这样的查询，它依据category列来排序，但没有明确规定依赖的id和rating列：

mysql> SELECT * FROM ratings ORDER BY category;

+----+----------+--------+

| id | category | rating |

+----+----------+--------+

|  1 |        1 |    4.5 |

|  5 |        1 |    3.2 |

|  3 |        2 |    3.7 |

|  4 |        2 |    3.5 |

|  6 |        2 |    3.5 |

|  2 |        3 |    5.0 |

|  7 |        3 |    2.7 |

+----+----------+--------+

包括limit 也许影响在每一个category内部值的顺序。例如，这是一个合法的查询结果：

mysql> SELECT * FROM ratings ORDER BY category LIMIT 5;

+----+----------+--------+

| id | category | rating |

+----+----------+--------+

|  1 |        1 |    4.5 |

|  5 |        1 |    3.2 |

|  4 |        2 |    3.5 |

|  3 |        2 |    3.7 |

|  6 |        2 |    3.5 |

+----+----------+--------+

在任何情况下，在order by列中被排序的行，都是执行的sql标准。

如果你想要确保用不用limit都得到相同的行顺序，在order by列中增加额外的列来使得排序固定。例如，如果id值不同，你能使得相同category值的行根据id列的值来排序：

mysql> SELECT * FROM ratings ORDER BY category, id;

+----+----------+--------+

| id | category | rating |

+----+----------+--------+

|  1 |        1 |    4.5 |

|  5 |        1 |    3.2 |

|  3 |        2 |    3.7 |

|  4 |        2 |    3.5 |

|  6 |        2 |    3.5 |

|  2 |        3 |    5.0 |

|  7 |        3 |    2.7 |

+----+----------+--------+

mysql> SELECT * FROM ratings ORDER BY category, id LIMIT 5;

+----+----------+--------+

| id | category | rating |

+----+----------+--------+

|  1 |        1 |    4.5 |

|  5 |        1 |    3.2 |

|  3 |        2 |    3.7 |

|  4 |        2 |    3.5 |

|  6 |        2 |    3.5 |

+----+----------+--------+

到此关于limit 的优化就结束了，接下来我们要说明的是1.17Function Call Optimization