MySQL中的limit分頁優化

MySQL的limit優化

mysql的分頁比較簡單，只須要limit offset,length就能夠獲取數據了，可是當offset和length比較大的時候，mysql明顯性能降低

1.子查詢優化法

先找出第一條數據，而後大於等於這條數據的id就是要獲取的數據
缺點：數據必須是連續的，能夠說不能有where條件，where條件會篩選數據，致使數據失去連續性，具體方法請看下面的查詢實例：
複製代碼 代碼以下:

mysql> set profiling=1;
Query OK, 0 rows affected (0.00 sec)

mysql> select count(*) from Member;
+----------+
| count(*) |
+----------+
|   169566 |
+----------+
1 row in set (0.00 sec)

mysql> pager grep !~-
PAGER set to 'grep !~-'

mysql> select * from Member limit 10, 100;
100 rows in set (0.00 sec)

mysql> select * from Member where MemberID >= (select MemberID from Member limit 10,1) limit 100;
100 rows in set (0.00 sec)

mysql> select * from Member limit 1000, 100;
100 rows in set (0.01 sec)

mysql> select * from Member where MemberID >= (select MemberID from Member limit 1000,1) limit 100;
100 rows in set (0.00 sec)

mysql> select * from Member limit 100000, 100;
100 rows in set (0.10 sec)

mysql> select * from Member where MemberID >= (select MemberID from Member limit 100000,1) limit 100;
100 rows in set (0.02 sec)

mysql> nopager
PAGER set to stdout


mysql> show profiles\G
*************************** 1. row ***************************
Query_ID: 1
Duration: 0.00003300
   Query: select count(*) from Member

*************************** 2. row ***************************
Query_ID: 2
Duration: 0.00167000
   Query: select * from Member limit 10, 100
*************************** 3. row ***************************
Query_ID: 3
Duration: 0.00112400
   Query: select * from Member where MemberID >= (select MemberID from Member limit 10,1) limit 100

*************************** 4. row ***************************
Query_ID: 4
Duration: 0.00263200
   Query: select * from Member limit 1000, 100
*************************** 5. row ***************************
Query_ID: 5
Duration: 0.00134000
   Query: select * from Member where MemberID >= (select MemberID from Member limit 1000,1) limit 100

*************************** 6. row ***************************
Query_ID: 6
Duration: 0.09956700
   Query: select * from Member limit 100000, 100
*************************** 7. row ***************************
Query_ID: 7
Duration: 0.02447700
   Query: select * from Member where MemberID >= (select MemberID from Member limit 100000,1) limit 100

從結果中能夠得知，當偏移1000以上使用子查詢法能夠有效的提升性能。

2.倒排表優化法

倒排表法相似創建索引，用一張表來維護頁數，而後經過高效的鏈接獲得數據

缺點：只適合數據數固定的狀況，數據不能刪除，維護頁表困難

倒排表介紹：（而倒排索引具稱是搜索引擎的算法基石）

倒排表是指存放在內存中的可以追加倒排記錄的倒排索引。倒排表是迷你的倒排索引。

臨時倒排文件是指存放在磁盤中，以文件的形式存儲的不可以追加倒排記錄的倒排索引。臨時倒排文件是中等規模的倒排索引。

最終倒排文件是指由存放在磁盤中，以文件的形式存儲的臨時倒排文件歸併獲得的倒排索引。最終倒排文件是較大規模的倒排索引。

倒排索引做爲抽象概念，而倒排表、臨時倒排文件、最終倒排文件是倒排索引的三種不一樣的表現形式。

3.反向查找優化法

當偏移超過一半記錄數的時候，先用排序，這樣偏移就反轉了

缺點：order by優化比較麻煩，要增長索引，索引影響數據的修改效率，而且要知道總記錄數 ，偏移大於數據的一半

limit偏移算法：
正向查找： (當前頁 - 1) * 頁長度
反向查找： 總記錄 - 當前頁 * 頁長度

作下實驗，看看性能如何

總記錄數：1,628,775
每頁記錄數： 40
總頁數：1,628,775 / 40 = 40720
中間頁數：40720 / 2 = 20360

第21000頁
正向查找SQL:
複製代碼 代碼以下:
SELECT * FROM `abc` WHERE `BatchID` = 123 LIMIT 839960, 40 

時間：1.8696 秒

反向查找sql:
複製代碼 代碼以下:
SELECT * FROM `abc` WHERE `BatchID` = 123 ORDER BY InputDate DESC LIMIT 788775, 40

時間：1.8336 秒

第30000頁
正向查找SQL: 
複製代碼 代碼以下:
SELECT * FROM `abc` WHERE `BatchID` = 123 LIMIT 1199960, 40 

時間：2.6493 秒

反向查找sql:
複製代碼 代碼以下:
SELECT * FROM `abc` WHERE `BatchID` = 123 ORDER BY InputDate DESC LIMIT 428775, 40 

時間：1.0035 秒

注意，反向查找的結果是是降序desc的，而且InputDate是記錄的插入時間，也能夠用主鍵聯合索引，可是不方便。

4.只查索引法

MySQL的limit工做原理就是先讀取n條記錄，而後拋棄前n條，讀m條想要的，因此n越大，性能會越差。
優化前SQL:
複製代碼 代碼以下:
SELECT * FROM member ORDER BY last_active LIMIT 50,5

優化後SQL:
複製代碼 代碼以下:
SELECT * FROM member INNER JOIN (SELECT member_id FROM member ORDER BY last_active LIMIT 50, 5) USING (member_id)

區別在於，優化前的SQL須要更多I/O浪費，由於先讀索引，再讀數據，而後拋棄無需的行。而優化後的SQL(子查詢那條)只讀索引(Cover index)就能夠了，而後經過member_id讀取須要的列。

總結：limit的優化限制都比較多，因此實際狀況用或者不用只能具體狀況具體分析了。頁數那麼後，基本不多人看的。。。

---

---

在mysql中limit能夠實現快速分頁，可是若是數據到了幾百萬時咱們的limit必須優化纔能有效的合理的實現分頁了，不然可能卡死你的服務器哦。

   當一個表數據有幾百萬的數據的時候成了問題！

   如 * from table limit 0,10 這個沒有問題 當 limit 200000,10 的時候數據讀取就很慢，能夠按照一下方法解決
    第一頁會很快
   PERCONA PERFORMANCE CONFERENCE 2009上，來自雅虎的幾位工程師帶來了一篇」EfficientPagination Using MySQL」的報告
   limit10000,20的意思掃描知足條件的10020行，扔掉前面的10000行，返回最後的20行，問題就在這裏。
   LIMIT 451350 , 30 掃描了45萬多行，怪不得慢的都堵死了。
   可是
   limit 30 這樣的語句僅僅掃描30行。

   那麼若是咱們以前記錄了最大ID，就能夠在這裏作文章

   舉個例子

   平常分頁SQL語句
   select id,name,content from users order by id asc limit 100000,20
   掃描100020行
   若是記錄了上次的最大ID
   select id,name,content from users where id>100073 order by id asc limit 20
   掃描20行。
   總數據有500萬左右
   如下例子 當時候 select * from wl_tagindex where byname='f' order by id limit 300000,10 執行時間是 3.21s
   優化後：

點擊(此處)摺疊或打開

select * from (
   select id from wl_tagindex
   where byname='f' order by id limit 300000,10
) a
left join wl_tagindex b on a.id=b.id

   執行時間爲 0.11s 速度明顯提高
   這裏須要說明的是 我這裏用到的字段是 byname ,id 須要把這兩個字段作複合索引，不然的話效果提高不明顯

   總結

   當一個數據庫表過於龐大，LIMIT offset, length中的offset值過大，則SQL查詢語句會很是緩慢，你需增長order by，而且order by字段須要創建索引。
   若是使用子查詢去優化LIMIT的話，則子查詢必須是連續的，某種意義來說，子查詢不該該有where條件，where會過濾數據，使數據失去連續性。
   若是你查詢的記錄比較大，而且數據傳輸量比較大，好比包含了text類型的field，則能夠經過創建子查詢。

   SELECT id,title,content FROM items WHERE id IN (SELECT id FROM items ORDER BY id limit 900000, 10);

   若是limit語句的offset較大，你能夠經過傳遞pk鍵值來減少offset = 0，這個主鍵最好是int類型而且auto_increment

   SELECT * FROM users WHERE uid > 456891 ORDER BY uid LIMIT 0, 10;

   這條語句，大意以下:

   SELECT * FROM users WHERE uid >=  (SELECT uid FROM users ORDER BY uid limit 895682, 1) limit 0, 10;
   若是limit的offset值過大，用戶也會翻頁疲勞，你能夠設置一個offset最大的，超過了能夠另行處理，通常連續翻頁過大，用戶體驗不好，則應該提供更優的用戶體驗給用戶。

 
 

---

---

 

原文地址：SQL優化：limit分頁優化 做者：wyett

分頁查詢

分頁查詢的問題點主要集中在

1. 如何快速定位起始點
2. 減小無用數據緩存

mysql爲分頁查詢提供了很方便的關鍵字limit，但這個關鍵字在數據量較大時，卻很低效。
「limit m,n」關鍵字的意思是，從第m行開始，掃描知足條件的n個偏移行。若需從第1行開始，則不須要指定m值。

示例

表aaaaa中共有2375690數據。

優化前的SQL  

SQL執行結果：

SELECT DISTINCT(device_id) uid FROM aaaaa WHERE status = 0 LIMIT 88000,1000;
1000 rows in set (0.48 sec)

 

SQL執行計劃：

MariaDB [star]> explain SELECT sql_no_cache DISTINCT(device_id) uid FROM aaaaa WHERE status = 0 LIMIT 88000,1000;
+------+-------------+---------------+------+---------------+------+---------+------+---------+------------------------------+
| id   | select_type | table         | type | possible_keys | key  | key_len | ref  | rows    | Extra                        |
+------+-------------+---------------+------+---------------+------+---------+------+---------+------------------------------+
|    1 | SIMPLE      | aaaaa         | ALL  | NULL          | NULL | NULL    | NULL | 2375690 | Using where; Using temporary |
+------+-------------+---------------+------+---------------+------+---------+------+---------+------------------------------+

  優化方式  

迅速定位起始ID，利用主鍵索引，加快掃描速度。能夠看到，derived中，SQL使用到了覆蓋索引進行掃描，雖然仍是全表掃，由於只掃描id列，大大下降了掃描的IO耗費，快速定位到了id。

MariaDB [star]> explain SELECT sql_no_cache DISTINCT(device_id) uid FROM aaaaa join (select id from aaaaa limit 88000,1) k on star_device_5.id>=k.id

 

where status=0 limit 1000; 
+------+-------------+---------------+-------+---------------+-------------+---------+------+---------+------------------------------------------------+
| id   | select_type | table         | type  | possible_keys | key         | key_len | ref  | rows    | Extra                                          |
+------+-------------+---------------+-------+---------------+-------------+---------+------+---------+------------------------------------------------+
|    1 | PRIMARY     |     | ALL   | NULL          | NULL        | NULL    | NULL |   88001 | Using temporary                                |
|    1 | PRIMARY     | star_device_5 | ALL   | PRIMARY       | NULL        | NULL    | NULL | 2377112 | Range checked for each record (index map: 0x1) |
|    2 | DERIVED     | star_device_5 | index | NULL          | idx_star_id | 8       | NULL | 2377112 | Using index                                    |
+------+-------------+---------------+-------+---------------+-------------+---------+------+---------+------------------------------------------------+

 

執行結果：

SELECT sql_no_cache DISTINCT(device_id) uid FROM star_device_5 join (select id from star_device_5 limit 880000,1) k on star_device_5.id>=k.id

 

where status=0 limit 1000;
1000 rows in set (0.19 sec)

 

隨着m的增大和n的增大，兩種寫法的SQL執行時間會有本質差異。我作了測試，當m值增長到880000時，優化前的SQL須要2分鐘，優化後的SQL仍是0.1s左右。

 
 

---

---

MySQL5.6中Limit的工做機制

若是你僅須要在一個結果集中返回特定的幾行，一般是使用limit，而不是取回整個結果集再捨去不須要的數據，MySQL一般按照以下的方式優化一個包含limit row_count或HAVING的語句：

◎只有limit

若是你只經過limit返回少許的行，那麼正常狀況下mysql會使用全盤掃描，有些場合會使用索引，如下是使用了覆蓋索引的狀況：

如下是使用全表掃描的狀況：

 

◎order by和limit

若是你order by和limit一塊兒使用，那麼mysql在排序結果中找到最初的row_count行以後就會完成這條語句，而不是對整個結果集進行排序。若是使用了索引排序，它就很是快地完成。若是整個filesort必須都作完的話，那麼在找到最初的row_count行以前，匹配該查詢的全部行都將被select，而且作sort操做。若是這些行找到了，mysql將不會對剩餘的結果集進行排序。

◎distinct和limit

當limit row_count和distinct一塊兒使用時，MySQL在找到最初的unique的row_count行以後就會中止檢索。

◎group by和limit

在某些場合下，group by會用於某些key行的排序，而且計算彙總信息，這時若是使用limit row_count的話將不會計算任何額外的grup by值。

◎SQL_CALC_FOUND_ROWS和limit

只要MySQL已經返回了須要的行數給客戶端，它將終止這個查詢，除非你在查詢中使用了SQL_CALC_FOUND_ROWS。

◎limit 0的用法

Limit 0會很是快地返回一個空結果，這個功能可被應用於檢測一條SQL的合法性。

◎臨時表和limit

若是服務器在查詢中使用了臨時表，它會使用limit row_count語句來計算需求的空間大小。

 

Order by和Limit混合使用引發的問題

若是在order by語句中返回的結果集有不少行，那麼非排序的列的返回結果是不肯定的，即隨機的，因此若是配合limit的話每次返回的結果集的順序是不固定的，好比下面這個例子

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之後，可發現id列和rating列和以前的結果集順序有出入：

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你須要的那幾列了：

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 |

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

 

Order by和limit一塊兒使用的優化原理

從MySQL5.6.2版本之後，優化器將更加智能地處理下面形式的查詢了

SELECT ... FROM single_table ... ORDER BY non_index_column [DESC] LIMIT [M,]N;

這種在很大的結果集中只返回不多的行數的查詢類型在web應用中很是常見，好比

SELECT col1, ... FROM t1 ... ORDER BY name LIMIT 10;

SELECT col1, ... FROM t1 ... ORDER BY RAND() LIMIT 15;

 

排序緩存有一個參數是sort_buffer_size，若是這個參數大小足夠上面範例中的N行的排序結果集(若是M也被定義，那就是M+N行的結果集大小)，那麼服務器將會避免一個文件排序操做，使得排序徹底在內存中完成。

內存排序+limit原理

1 掃描表，在內存中插入那些被選擇排序的列的數據到一個排好序的隊列中，好比order by col1，col2，則插入col1和col2列的數據。若是隊列滿了，則擠出排序在末尾的數據。

2 返回隊列中的前N行記錄，若是M也被定義，則調到第M行開始返回後續的N行記錄。

 

文件排序+limit原理

1掃描表，重複步驟2和3，直到表的結尾

2選中這些行數直到排序緩存被填滿

3在排序緩存中寫入第一個N行（若是M被定義，則M+N行）到一個排序文件中。

 

二者比較

在內存中排序和使用文件排序相比，掃描表的代價幾乎是同樣的，不一樣的是其餘的開銷：

內存排序的方法在插入數據到一個有序隊列中會牽扯到更多的cpu資源，而文件排序會消耗更多的磁盤IO，優化器在考慮二者的平衡性上會主要考慮N的值大小

 
 

---

---

LIMIT是什麼?

  LIMIT的概念,其實你們應該都很清楚,在百度百科中是這樣描述的:

LIMIT是一種數據語言，主要是用於查詢以後要顯示返回的前幾條或者中間某幾行數據。

這裏着重須要注意的是,offset爲開始角標,count表明數量,以下圖所示:

(網絡配圖)

理解了這個概念以後,咱們就可以知道下面這兩個語句的意思了:

LIMIT 0,100; (A)
LIMIT 10,100; (B)

語句A表明的是 :  從起始角標爲0的位置,日後獲取100條記錄。

語句B表明的是 :  從起始角標爲10的位置,日後獲取100條記錄。

(別覺得這很簡單,在以前的面試過程當中,就有不少童鞋搞混了,將語句B理解成了: 從起始角標爲10的位置,獲取90條數據呢。)

其實,LIMIT還有一個比較經常使用的簡化寫法,以下所示:

LIMIT 100;

這其實就是對上述A語句的簡化,其意思表明的是: 從其實角標爲0的位置,日後獲取100條記錄。只是將其實角標0省略掉了而已。真是這樣的特性,有不少應用也直接使用LIMIT來進行分頁操做。

提問時間

  上面咱們介紹了,LIMIT的概念,也理清楚了LIMIT每一個參數的含義,那如今就留一個問題:

• 問: LIMIT 0,100與 LIMIT 100000,100的執行效率是同樣嗎？ 同樣爲何？不同又爲何？

ps: 面試時常常有這樣的問題哦。這個以前我也被問到過。

執行LIMIT發生了什麼?

  咱們知道,通常是在order by xx asc|desc語句後緊跟着LIMIT語句,下面咱們就來看看下面這兩個語句,揭露一下:
語句A:

select * from t_base_user order by oid desc limit 0,100;

語句B:

select * from t_base_user order by oid desc limit 10000,100;

分別看下執行計劃:
語句A的執行計劃是:

explain select * from t_base_user order by oid desc limit 0,100;

結果:

id	select_type	table	type	possible_keys	key	key_len	ref	rows	Extra
1	SIMPLE	t_base_user	index	null	PRIMARY	8	null	100	null

語句B的執行計劃是:

explain select * from t_base_user order by oid desc limit 10000,100;

結果:
id|select_type|table|type|possible_keys|key|key_len|ref|rows|Extra
—|—|—|—|—|—|—|—|–|–|
1 | SIMPLE|t_base_user|index|null|PRIMARY|8|null|1000100|null

到這裏,咱們會發現掃描的行數是徹底不同的,在語句B中,其實MySQL實際掃描1000100行記錄,而後只返回100條記錄,將前面的1000000條記錄活生生的拋棄掉，你說這成本大不大,代價高不高？ 看到這裏,咱們應該已經知道上面問題的答案了。

如何優化

  如今咱們來講說如何優化LIMIT，咱們知道,在offset比較大的時候,效率會很是低,因此,對LIMIT優化,要麼限制分頁的數量,要麼下降offset的大小。
例如:

select * from t_base_user limit 100000,100

好比上面這語句,由於咱們主鍵是連續的。

方法一 : 咱們就能夠經過這樣來優化:

select * from t_base_user where oid between 100000 and 1000100;

此時若是咱們看執行計劃的話,其實type已經從all(全表掃描)掃描優化到range(範圍查找),也走了PRIMARY索引。

方法二: 咱們能夠倒序LIMIT
若是咱們表中一共有120萬數據,此時咱們就能夠倒序LIMIT,以下所述:

select * from t_base_user order by oid desc limit 100;

或者這樣:

select * from t_base_user where oid<1000000 order by oid desc limit 100;

一樣也達到來優化的效果。

數據結構

  本文全部數據,均基於如下數據結構:

create table t_base_user(
oid bigint(20) not null primary key auto_increment,
name varchar(30) null comment 「name」,
email varchar(30) null comment 「email」,
age int null comment 「age」,
telephone varchar(30) null comment 「telephone」,
status tinyint(4) null comment 「0 無效 1 有效」,
created_at datetime null default now() comment 「建立時間」,
updated_at datetime null default now() comment 「修改時間」
)
// 新增記錄:
insert into t_base_user(name,email,age,telephone,status,created_at,updated_at) values (「andyqian」,」andytohome」,20,」15608411」,1,now(),now());

這裏提供一個簡單的方法複製數據

insert into t_base_user(name,email,age,telephone,status) select name,email,age,telephone,status from t_base_user;

使用該語句,能夠快速的複製數據。執行屢次後,就可以生成很多數據,(備註: 該數據僅用做LIMIT關鍵字演示,新建索引,計算區分度其值誤差會比較大,請勿將該結果做爲建索引的參考值。)

小結

  上面對MySQL LIMIT關鍵字作了詳細的講解,你可別小瞧它哦，它在平時開發中有很大的用處哦,例如: 在平時開發查詢數據時，加上LIMIT後，查詢效果可會大大增長,能節省很多時間呢。在查詢數據時養成加上LIMIT是一個不錯的習慣。