MYSQL分頁limit速度太慢的優化辦法。本站提示廣大學習愛好者：（MYSQL分頁limit速度太慢的優化辦法）文章只能為提供參考，不一定能成為您想要的結果。以下是MYSQL分頁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最年夜的，跨越了可以另行處置，普通持續翻頁過年夜，用戶體驗很差，則應當供給更優的用戶體驗給用戶。
limit 分頁優化辦法
1.子查詢優化法
先找出第一條數據，然後年夜於等於這條數據的id就是要獲得的數據
缺陷：數據必需是持續的，可以說不克不及有where前提，where前提會挑選數據，招致數據掉去持續性
試驗下
mysql> set profi=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 profilesG
*************************** 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:
Sql代碼
SELECT * FROM `abc` WHERE `BatchID` = 123 LIMIT 839960, 40
時光：1.8696 秒
反向查找sql:
Sql代碼
SELECT * FROM `abc` WHERE `BatchID` = 123 ORDER BY InputDate DESC LIMIT 788775, 40
時光：1.8336 秒
第30000頁
正向查找SQL:
Sql代碼
1.SELECT * FROM `abc` WHERE `BatchID` = 123 LIMIT 1199960, 40
SELECT * FROM `abc` WHERE `BatchID` = 123 LIMIT 1199960, 40
時光：2.6493 秒
反向查找sql:
Sql代碼
1.SELECT * FROM `abc` WHERE `BatchID` = 123 ORDER BY InputDate DESC LIMIT 428775, 40
SELECT * FROM `abc` WHERE `BatchID` = 123 ORDER BY InputDate DESC LIMIT 428775, 40
時光：1.0035 秒
留意，反向查找的成果是是降序desc的，而且InputDate是記載的拔出時光，也能夠用主鍵結合索引，然則不便利。
4.limit限制優化法
把limit偏移量限制低於某個數。。跨越這個數等於沒數據，我記得alibaba的dba說過他們是如許做的
5.只查索引法
