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