MySQL分頁查詢的性能優化

 MySQL limit分頁查詢的性能優化

 

Mysql的分頁查詢十分簡單，但是當數據量大的時候一般的分頁就吃不消了。

傳統分頁查詢：SELECT c1,c2,cn… FROM table LIMIT n,m

MySQL的limit工作原理就是先讀取前面n條記錄，然后拋棄前n條，讀后面m條想要的，所以n越大，偏移量越大，性能就越差。

推薦分頁查詢方法：

1、盡量給出查詢的大致范圍

1. SELECT c1,c2,cn... FROM table WHERE id>=20000 LIMIT 10;

2、子查詢法

1. SELECT c1,c2,cn... FROM table WHERE id>=
2. (
3. SELECT id FROM table LIMIT 20000,1
4. )
5. LIMIT 10;

3、高性能MySQL一書中提到的只讀索引方法

優化前SQL:

1. SELECT c1,c2,cn... FROM member ORDER BY last_active LIMIT 50,5

優化后SQL:

1. SELECT c1, c2, cn .. .
2. FROM member
3. INNER JOIN (SELECT member_id FROM member ORDER BY last_active LIMIT 50, 5)
4. USING (member_id)

分別在於，優化前的SQL需要更多I/O浪費，因為先讀索引，再讀數據，然后拋棄無需的行。而優化后的SQL(子查詢那條)只讀索引(Cover index)就可以了，然后通過member_id讀取需要的列。

4、第一步用用程序讀取出ID，然后再用IN方法讀取所需記錄

程序讀ID：

1. SELECT id FROM table LIMIT 20000, 10;
2. SELECT c1, c2, cn .. . FROM table WHERE id IN (id1, id2, idn.. .)

 

 

==============

 

 

MySQL的limit用法和分頁查詢的性能分析及優化

一、limit用法

在我們使用查詢語句的時候，經常要返回前幾條或者中間某幾行數據，這個時候怎么辦呢？不用擔心，mysql已經為我們提供了這樣一個功能。

SELECT * FROM table LIMIT [offset,] rows | `rows OFFSET offset ` (LIMIT offset, `length`) SELECT * FROM table where condition1 = 0 and condition2 = 0 and condition3 = -1 and condition4 = -1 order by id asc LIMIT 2000 OFFSET 50000 

LIMIT 子句可以被用於強制 SELECT 語句返回指定的記錄數。LIMIT 接受一個或兩個數字參數。參數必須是一個整數常量。如果給定兩個參數，第一個參數指定第一個返回記錄行的偏移量，第二個參數指定返回記錄行的最大數目。初始記錄行的偏移量是 0(而不是 1)： 為了與 PostgreSQL 兼容，MySQL 也支持句法： LIMIT # OFFSET #。

mysql> SELECT * FROM table LIMIT 5,10; // 檢索記錄行 6-15 

//為了檢索從某一個偏移量到記錄集的結束所有的記錄行，可以指定第二個參數為 -1：

mysql> SELECT * FROM table LIMIT 95,-1; // 檢索記錄行 96-last. 

//如果只給定一個參數，它表示返回最大的記錄行數目：
mysql> SELECT * FROM table LIMIT 5; //檢索前 5 個記錄行
//換句話說，LIMIT n 等價於 LIMIT 0,n。

二、Mysql的分頁查詢語句的性能分析

MySql分頁sql語句，如果和MSSQL的TOP語法相比，那么MySQL的LIMIT語法要顯得優雅了許多。使用它來分頁是再自然不過的事情了。

最基本的分頁方式：

SELECT ... FROM ... WHERE ... ORDER BY ... LIMIT ... 

在中小數據量的情況下，這樣的SQL足夠用了，唯一需要注意的問題就是確保使用了索引：
舉例來說，如果實際SQL類似下面語句，那么在category_id, id兩列上建立復合索引比較好：

SELECT * FROM articles WHERE category_id = 123 ORDER BY id LIMIT 50, 10 

子查詢的分頁方式：

隨着數據量的增加，頁數會越來越多，查看后幾頁的SQL就可能類似：
SELECT * FROM articles WHERE category_id = 123 ORDER BY id LIMIT 10000, 10

一言以蔽之，就是越往后分頁，LIMIT語句的偏移量就會越大，速度也會明顯變慢。
此時，我們可以通過子查詢的方式來提高分頁效率，大致如下：

SELECT * FROM articles WHERE id >= (SELECT id FROM articles WHERE category_id = 123 ORDER BY id LIMIT 10000, 1) LIMIT 10 

JOIN分頁方式

SELECT * FROM `content` AS t1 JOIN (SELECT id FROM `content` ORDER BY id desc LIMIT ".($page-1)*$pagesize.", 1) AS t2 WHERE t1.id <= t2.id ORDER BY t1.id desc LIMIT $pagesize; 

經過我的測試，join分頁和子查詢分頁的效率基本在一個等級上，消耗的時間也基本一致。
explain SQL語句：

id select_type table type possible_keys key key_len ref rows Extra 1 PRIMARY <derived2> system NULL NULL NULL NULL 1 1 PRIMARY t1 range PRIMARY PRIMARY 4 NULL 6264 Using where 2 DERIVED content index NULL PRIMARY 4 NULL 27085 Using index 

---

為什么會這樣呢？因為子查詢是在索引上完成的，而普通的查詢時在數據文件上完成的，通常來說，索引文件要比數據文件小得多，所以操作起來也會更有效率。

實際可以利用類似策略模式的方式去處理分頁，比如判斷如果是一百頁以內，就使用最基本的分頁方式，大於一百頁，則使用子查詢的分頁方式。

三、對於有大數據量的mysql表來說，使用LIMIT分頁存在很嚴重的性能問題。

查詢從第1000000之后的30條記錄：

SQL代碼1：平均用時6.6秒 SELECT * FROM `cdb_posts` ORDER BY pid LIMIT 1000000 , 30 SQL代碼2：平均用時0.6秒 SELECT * FROM `cdb_posts` WHERE pid >= (SELECT pid FROM `cdb_posts` ORDER BY pid LIMIT 1000000 , 1) LIMIT 30 

因為要取出所有字段內容，第一種需要跨越大量數據塊並取出，而第二種基本通過直接根據索引字段定位后，才取出相應內容，效率自然大大提升。對limit的優化，不是直接使用limit，而是首先獲取到offset的id，然后直接使用limit size來獲取數據。

可以看出，越往后分頁，LIMIT語句的偏移量就會越大，兩者速度差距也會越明顯。

實際應用中，可以利用類似策略模式的方式去處理分頁，比如判斷如果是一百頁以內，就使用最基本的分頁方式，大於一百頁，則使用子查詢的分頁方式。

優化思想：避免數據量大時掃描過多的記錄

為了保證index索引列連續，可以為每個表加一個自增字段，並且加上索引

參考：mysql分頁offset過大，Sql優化經驗

 

 

========

 

 

MySQL單表百萬數據記錄分頁性能優化

背景：

自己的一個網站，由於單表的數據記錄高達了一百萬條，造成數據訪問很慢，Google分析的后台經常報告超時，尤其是頁碼大的頁面更是慢的不行。

測試環境：

先讓我們熟悉下基本的sql語句，來查看下我們將要測試表的基本信息

use infomation_schema
SELECT * FROM TABLES WHERE TABLE_SCHEMA = ‘dbname’ AND TABLE_NAME = ‘product’

查詢結果：

從上圖中我們可以看到表的基本信息：

表行數：866633
平均每行的數據長度：5133字節
單表大小：4448700632字節

關於行和表大小的單位都是字節，我們經過計算可以知道
平均行長度：大約5k
單表總大小：4.1g
表中字段各種類型都有varchar、datetime、text等，id字段為主鍵

測試實驗

1.   直接用limit start, count分頁語句， 也是我程序中用的方法：

select * from product limit start, count
當起始頁較小時，查詢沒有性能問題，我們分別看下從10， 100， 1000， 10000開始分頁的執行時間（每頁取20條）， 如下：

select * from product limit 10, 20   0.016秒
select * from product limit 100, 20   0.016秒
select * from product limit 1000, 20   0.047秒
select * from product limit 10000, 20   0.094秒

我們已經看出隨着起始記錄的增加，時間也隨着增大， 這說明分頁語句limit跟起始頁碼是有很大關系的，那么我們把起始記錄改為40w看下（也就是記錄的一般左右）                                    select * from product limit 400000, 20   3.229秒

再看我們取最后一頁記錄的時間
select * from product limit 866613, 20   37.44秒

難怪搜索引擎抓取我們頁面的時候經常會報超時，像這種分頁最大的頁碼頁顯然這種時
間是無法忍受的。

從中我們也能總結出兩件事情：
1）limit語句的查詢時間與起始記錄的位置成正比
2）mysql的limit語句是很方便，但是對記錄很多的表並不適合直接使用。

2.   對limit分頁問題的性能優化方法

利用表的覆蓋索引來加速分頁查詢
我們都知道，利用了索引查詢的語句中如果只包含了那個索引列（覆蓋索引），那么這種情況會查詢很快。

因為利用索引查找有優化算法，且數據就在查詢索引上面，不用再去找相關的數據地址了，這樣節省了很多時間。另外Mysql中也有相關的索引緩存，在並發高的時候利用緩存就效果更好了。

在我們的例子中，我們知道id字段是主鍵，自然就包含了默認的主鍵索引。現在讓我們看看利用覆蓋索引的查詢效果如何：

這次我們之間查詢最后一頁的數據（利用覆蓋索引，只包含id列），如下：
select id from product limit 866613, 20 0.2秒
相對於查詢了所有列的37.44秒，提升了大概100多倍的速度

那么如果我們也要查詢所有列，有兩種方法，一種是id>=的形式，另一種就是利用join，看下實際情況：

SELECT * FROM product WHERE ID > =(select id from product limit 866613, 1) limit 20
查詢時間為0.2秒，簡直是一個質的飛躍啊，哈哈

另一種寫法
SELECT * FROM product a JOIN (select id from product limit 866613, 20) b ON a.ID = b.id
查詢時間也很短，贊！

其實兩者用的都是一個原理嘛，所以效果也差不多