mysql分頁與分頁性能查詢優化

mysql分頁就直接使用limit進行操作，limit如果我們直接不加任何處理可能數據大了就會很卡的，下面我來給大家介紹mysql分頁實例與分頁性能優化。

一，最常見MYSQL最基本的分頁方式：

 代碼如下 復制代碼

select * from content order by id desc limit 0, 10

在中小數據量的情況下，這樣的SQL足夠用了，唯一需要注意的問題就是確保使用了索引。隨著數據量的增加，頁數會越來越多，查看後幾頁的SQL就可能類似：

 代碼如下 復制代碼

select * from content order by id desc limit 10000, 10

一言以蔽之，就是越往後分頁，LIMIT語句的偏移量就會越大，速度也會明顯變慢。

MYSQL分頁性能優化

limit 10000,20的意思掃描滿足條件的10020行，扔掉前面的10000行，返回最後的20行，問題就在這裡，如果是limit 100000,100，需要掃描100100行，在一個高並發的應用裡，每次查詢需要掃描超過10W行，性能肯定大打折扣。文中還提到limit n性能是沒問題的，因為只掃描n行。

文中提到一種”clue”的做法，給翻頁提供一些”線索”，比如還是SELECT * FROM message ORDER BY id DESC，按id降序分頁，每頁20條，當前是第10頁，當前頁條目id最大的是9527，最小的是9500，如果我們只提供”上一頁”、”下一頁”這樣的跳轉（不提供到第N頁的跳轉），那麼在處理”上一頁”的時候SQL語句可以是：

 代碼如下 復制代碼

SELECT * FROM message WHERE id > 9527 ORDER BY id ASC LIMIT 20;

處理”下一頁”的時候SQL語句可以是：

 代碼如下 復制代碼

SELECT * FROM message WHERE id < 9500 ORDER BY id DESC LIMIT 20;

不管翻多少頁，每次查詢只掃描20行。

缺點是只能提供”上一頁”、”下一頁”的鏈接形式，但是我們的產品經理非常喜歡”<上一頁 1 2 3 4 5 6 7 8 9 下一頁>”這樣的鏈接方式，怎麼辦呢？

如果LIMIT m,n不可避免的話，要優化效率，只有盡可能的讓m小一下，我們擴展前面的”clue”做法，還是SELECT * FROM message ORDER BY id DESC，按id降序分頁，每頁20條，當前是第10頁，當前頁條目id最大的是9527，最小的是9500，比如要跳到第8頁，我看的SQL語句可以這樣寫：

 代碼如下 復制代碼

SELECT * FROM message WHERE id > 9527 ORDER BY id ASC LIMIT 20,20;

跳轉到第13頁：

 代碼如下 復制代碼

SELECT * FROM message WHERE id < 9500 ORDER BY id DESC LIMIT 40,20;

還有網友說可以使用子查詢來操作

一，子查詢的分頁方式來提高分頁效率，飄易用的SQL語句如下：

 代碼如下 復制代碼

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

為什麼會這樣呢？因為子查詢是在索引上完成的，而普通的查詢時在數據文件上完成的，通常來說，索引文件要比數據文件小得多，所以操作起來也會更有效率。（via）通過explain SQL語句發現：子查詢使用了索引！

 代碼如下 復制代碼

id select_type table type possible_keys key key_len ref rows Extra
1 PRIMARY content range PRIMARY PRIMARY 4 NULL 6264 Using where
2 SUBQUERY content index NULL PRIMARY 4 NULL 27085 Using index

經過飄易的實測，使用子查詢的分頁方式的效率比純LIMIT提高了14-20倍！

二，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

我們還可以使用分頁存儲過程代碼

 代碼如下 復制代碼

DELIMITER $$;
DROP PROCEDURE IF EXISTS `sp_page`$$
CREATE PROCEDURE `sp_page`(
 in _pagecurrent int,/*當前頁*/
 in _pagesize int,/*每頁的記錄數*/
 in _ifelse varchar(1000),/*顯示字段*/
 in _where varchar(1000),/*條件*/
 in _order varchar(1000)/*排序*/
)
COMMENT '分頁存儲過程'
BEGIN
 if _pagesize<=1 then
  set _pagesize=20;
 end if;
 if _pagecurrent < 1 then
  set _pagecurrent = 1;
 end if;
 
 set @strsql = concat('select ',_ifelse,' from ',_where,' ',_order,' limit ',_pagecurrent*_pagesize-_pagesize,',',_pagesize);
 prepare stmtsql from @strsql;
 execute stmtsql;
 deallocate prepare stmtsql;

 set @strsqlcount=concat('select count(1) as count from ',_where);/*count(1) 這個字段最好是主鍵*/
 prepare stmtsqlcount from @strsqlcount;
 execute stmtsqlcount;
 deallocate prepare stmtsqlcount;
END$$
DELIMITER ;$$

調用代碼

調用例1  call sp_Page(1,3,'*','test','order by id desc');

調用例2  call sp_Page(1,3,'*','test where sort=1','order by id desc');

調用例3  call sp_Page(1,3,'id,title','test where sort=1','order by id desc');