小編給大家分享一下MySQL中的LIMIT語句有什么用，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

成都創(chuàng)新互聯(lián)公司堅持“要么做到，要么別承諾”的工作理念，服務(wù)領(lǐng)域包括：網(wǎng)站制作、做網(wǎng)站、企業(yè)官網(wǎng)、英文網(wǎng)站、手機端網(wǎng)站、網(wǎng)站推廣等服務(wù)，滿足客戶于互聯(lián)網(wǎng)時代的拜泉網(wǎng)站設(shè)計、移動媒體設(shè)計的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡(luò)建設(shè)合作伙伴！

問題

為了故事的順利發(fā)展，我們得先有個表：

CREATE TABLE t (
    id INT UNSIGNED NOT NULL AUTO_INCREMENT,
    key1 VARCHAR(100),
    common_field VARCHAR(100),
    PRIMARY KEY (id),
    KEY idx_key1 (key1)
) Engine=InnoDB CHARSET=utf8;

表t包含3個列，id列是主鍵，key1列是二級索引列。表中包含1萬條記錄。

當(dāng)我們執(zhí)行下邊這個語句的時候，是使用二級索引idx_key1的：

mysql>  EXPLAIN SELECT * FROM t ORDER BY key1 LIMIT 1;
+----+-------------+-------+------------+-------+---------------+----------+---------+------+------+----------+-------+
| id | select_type | table | partitions | type  | possible_keys | key      | key_len | ref  | rows | filtered | Extra |
+----+-------------+-------+------------+-------+---------------+----------+---------+------+------+----------+-------+
|  1 | SIMPLE      | t     | NULL       | index | NULL          | idx_key1 | 303     | NULL |    1 |   100.00 | NULL  |
+----+-------------+-------+------------+-------+---------------+----------+---------+------+------+----------+-------+
1 row in set, 1 warning (0.00 sec)

這個很好理解，因為在二級索引idx_key1中，key1列是有序的。而查詢是要取按照key1列排序的第1條記錄，那MySQL只需要從idx_key1中獲取到第一條二級索引記錄，然后直接回表取得完整的記錄即可。

但是如果我們把上邊語句的LIMIT 1換成LIMIT 5000, 1，則卻需要進行全表掃描，并進行filesort，執(zhí)行計劃如下：

mysql>  EXPLAIN SELECT * FROM t ORDER BY key1 LIMIT 5000, 1;
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+----------------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra          |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+----------------+
|  1 | SIMPLE      | t     | NULL       | ALL  | NULL          | NULL | NULL    | NULL | 9966 |   100.00 | Using filesort |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+----------------+
1 row in set, 1 warning (0.00 sec)

有的同學(xué)就很不理解了：LIMIT 5000, 1也可以使用二級索引idx_key1呀，我們可以先掃描到第5001條二級索引記錄，對第5001條二級索引記錄進行回表操作不就好了么，這樣的代價肯定比全表掃描+filesort強呀。

很遺憾的告訴各位，由于MySQL實現(xiàn)上的缺陷，不會出現(xiàn)上述的理想情況，它只會笨笨的去執(zhí)行全表掃描+filesort，下邊我們嘮叨一下到底是咋回事兒。

server層和存儲引擎層

大家都知道，MySQL內(nèi)部其實是分為server層和存儲引擎層的：

• server層負責(zé)處理一些通用的事情，諸如連接管理、SQL語法解析、分析執(zhí)行計劃之類的東西

• 存儲引擎層負責(zé)具體的數(shù)據(jù)存儲，諸如數(shù)據(jù)是存儲到文件上還是內(nèi)存里，具體的存儲格式是什么樣的之類的。我們現(xiàn)在基本都使用InnoDB存儲引擎，其他存儲引擎使用的非常少了，所以我們也就不涉及其他存儲引擎了。

MySQL中一條SQL語句的執(zhí)行是通過server層和存儲引擎層的多次交互才能得到最終結(jié)果的。比方說下邊這個查詢：

SELECT * FROM t WHERE key1 > 'a' AND key1 < 'b' AND common_field != 'a';

server層會分析到上述語句可以使用下邊兩種方案執(zhí)行：

• 方案一：使用全表掃描

• 方案二：使用二級索引idx_key1，此時需要掃描key1列值在('a', 'b')之間的全部二級索引記錄，并且每條二級索引記錄都需要進行回表操作。

server層會分析上述兩個方案哪個成本更低，然后選取成本更低的那個方案作為執(zhí)行計劃。然后就調(diào)用存儲引擎提供的接口來真正的執(zhí)行查詢了。

這里假設(shè)采用方案二，也就是使用二級索引idx_key1執(zhí)行上述查詢。那么server層和存儲引擎層的對話可以如下所示：

server層：“hey，麻煩去查查idx_key1二級索引的('a', 'b')區(qū)間的第一條記錄，然后把回表后把完整的記錄返給我哈”

InnoDB：“收到，這就去查”，然后InnoDB就通過idx_key1二級索引對應(yīng)的B+樹，快速定位到掃描區(qū)間('a', 'b')的第一條二級索引記錄，然后進行回表，得到完整的聚簇索引記錄返回給server層。

server層收到完整的聚簇索引記錄后，繼續(xù)判斷common_field!='a'條件是否成立，如果不成立則舍棄該記錄，否則將該記錄發(fā)送到客戶端。然后對存儲引擎說：“請把下一條記錄給我哈”

小貼士：

此處將記錄發(fā)送給客戶端其實是發(fā)送到本地的網(wǎng)絡(luò)緩沖區(qū)，緩沖區(qū)大小由net_buffer_length控制，默認是16KB大小。等緩沖區(qū)滿了才真正發(fā)送網(wǎng)絡(luò)包到客戶端。

InnoDB：“收到，這就去查”。InnoDB根據(jù)記錄的next_record屬性找到idx_key1的('a', 'b')區(qū)間的下一條二級索引記錄，然后進行回表操作，將得到的完整的聚簇索引記錄返回給server層。

小貼士：

不論是聚簇索引記錄還是二級索引記錄，都包含一個稱作next_record的屬性，各個記錄根據(jù)next_record連成了一個鏈表，并且鏈表中的記錄是按照鍵值排序的（對于聚簇索引來說，鍵值指的是主鍵的值，對于二級索引記錄來說，鍵值指的是二級索引列的值）。

server層收到完整的聚簇索引記錄后，繼續(xù)判斷common_field!='a'條件是否成立，如果不成立則舍棄該記錄，否則將該記錄發(fā)送到客戶端。然后對存儲引擎說：“請把下一條記錄給我哈”

... 然后就不停的重復(fù)上述過程。

直到：

也就是直到InnoDB發(fā)現(xiàn)根據(jù)二級索引記錄的next_record獲取到的下一條二級索引記錄不在('a', 'b')區(qū)間中，就跟server層說：“好了，('a', 'b')區(qū)間沒有下一條記錄了”

server層收到InnoDB說的沒有下一條記錄的消息，就結(jié)束查詢。

現(xiàn)在大家就知道了server層和存儲引擎層的基本交互過程了。

那LIMIT是什么鬼？

說出來大家可能有點兒驚訝，MySQL是在server層準備向客戶端發(fā)送記錄的時候才會去處理LIMIT子句中的內(nèi)容。拿下邊這個語句舉例子：

SELECT * FROM t ORDER BY key1 LIMIT 5000, 1;

如果使用idx_key1執(zhí)行上述查詢，那么MySQL會這樣處理：

• server層向InnoDB要第1條記錄，InnoDB從idx_key1中獲取到第一條二級索引記錄，然后進行回表操作得到完整的聚簇索引記錄，然后返回給server層。server層準備將其發(fā)送給客戶端，此時發(fā)現(xiàn)還有個LIMIT 5000, 1的要求，意味著符合條件的記錄中的第5001條才可以真正發(fā)送給客戶端，所以在這里先做個統(tǒng)計，我們假設(shè)server層維護了一個稱作limit_count的變量用于統(tǒng)計已經(jīng)跳過了多少條記錄，此時就應(yīng)該將limit_count設(shè)置為1。

• server層再向InnoDB要下一條記錄，InnoDB再根據(jù)二級索引記錄的next_record屬性找到下一條二級索引記錄，再次進行回表得到完整的聚簇索引記錄返回給server層。server層在將其發(fā)送給客戶端的時候發(fā)現(xiàn)limit_count才是1，所以就放棄發(fā)送到客戶端的操作，將limit_count加1，此時limit_count變?yōu)榱?。

• ... 重復(fù)上述操作

• 直到limit_count等于5000的時候，server層才會真正的將InnoDB返回的完整聚簇索引記錄發(fā)送給客戶端。

從上述過程中我們可以看到，由于MySQL中是在實際向客戶端發(fā)送記錄前才會去判斷LIMIT子句是否符合要求，所以如果使用二級索引執(zhí)行上述查詢的話，意味著要進行5001次回表操作。server層在進行執(zhí)行計劃分析的時候會覺得執(zhí)行這么多次回表的成本太大了，還不如直接全表掃描+filesort快呢，所以就選擇了后者執(zhí)行查詢。

怎么辦？

由于MySQL實現(xiàn)LIMIT子句的局限性，在處理諸如LIMIT 5000, 1這樣的語句時就無法通過使用二級索引來加快查詢速度了么？其實也不是，只要把上述語句改寫成：

SELECT * FROM t, (SELECT id FROM t ORDER BY key1 LIMIT 5000, 1) AS d
    WHERE t.id = d.id;

這樣，SELECT id FROM t ORDER BY key1 LIMIT 5000, 1作為一個子查詢單獨存在，由于該子查詢的查詢列表只有一個id列，MySQL可以通過僅掃描二級索引idx_key1執(zhí)行該子查詢，然后再根據(jù)子查詢中獲得到的主鍵值去表t中進行查找。

這樣就省去了前5000條記錄的回表操作，從而大大提升了查詢效率！

以上是“MySQL中的LIMIT語句有什么用”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對大家有所幫助，如果還想學(xué)習(xí)更多知識，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道！

當(dāng)前標題：MySQL中的LIMIT語句有什么用
文章鏈接：http://jinyejixie.com/article20/jjppco.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供品牌網(wǎng)站設(shè)計、標簽優(yōu)化、、網(wǎng)站設(shè)計公司、微信公眾號、面包屑導(dǎo)航

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)