背景

1月22號晚上10點半，下班后愉快的坐在在回家的地鐵上，內心想著周末的生活怎么安排。sql

忽然電話響了起來，一看是咱們的一個開發同窗，頓時緊張了起來，本周的版本已經發布過了，這時候打電話通常來講是線上出問題了。數據庫

果真，溝通的狀況是線上的一個查詢數據的接口被瘋狂的失去理智般的調用，這個操做直接致使線上的MySql集群被拖慢了。性能優化

好吧，這問題算是嚴重了，下了地鐵匆匆趕到家，開電腦，跟同事把Pinpoint上的慢查詢日志撈出來。看到一個很奇怪的查詢，以下多線程

1 POST domain/v1.0/module/method?order=condition&orderType=desc&offset=1800000&limit=500

domain、module 和 method 都是化名，表明接口的域、模塊和實例方法名，后面的offset和limit表明分頁操做的偏移量和每頁的數量，也就是說該同窗是在 翻第(1800000/500+1=3601)頁。初步撈了一下日志，發現 有8000屢次這樣調用。dom

這太神奇了，并且咱們頁面上的分頁單頁數量也不是500，而是 25條每頁，這個絕對不是人為的在功能頁面上進行一頁一頁的翻頁操做，而是數據被刷了(說明下，咱們生產環境數據有1億+)。?詳細對比日志發現，不少分頁的時間是重疊的，對方應該是多線程調用。函數

經過對鑒權的Token的分析，基本定位了請求是來自一個叫作ApiAutotest的客戶端程序在作這個操做，也定位了生成鑒權Token的帳號來自一個QA的同窗。立馬打電話給同窗，進行了溝通和處理。工具

分析

其實對于咱們的MySQL查詢語句來講，總體效率仍是能夠的，該有的聯表查詢優化都有，該簡略的查詢內容也有，關鍵條件字段和排序字段該有的索引也都在，問題在于他一頁一頁的分頁去查詢，查到越后面的頁數，掃描到的數據越多，也就越慢。性能

咱們在查看前幾頁的時候，發現速度很是快，好比 ?limit?200,25，瞬間就出來了。可是越日后，速度就越慢，特別是百萬條以后，卡到不行，那這個是什么原理呢。先看一下咱們翻頁翻到后面時，查詢的sql是怎樣的：測試

1 select * from t_name where c_name1='xxx' order by c_name2 limit 2000000,25;

這種查詢的慢，實際上是由于limit后面的偏移量太大致使的。好比像上面的??limit 2000000,25?，這個等同于數據庫要掃描出 2000025條數據，而后再丟棄前面的 20000000條數據，返回剩下25條數據給用戶，這種取法明顯不合理。優化

你們翻看《高性能MySQL》第六章：查詢性能優化，對這個問題有過說明：

分頁操做一般會使用limit加上偏移量的辦法實現，同時再加上合適的order by子句。但這會出現一個常見問題：當偏移量很是大的時候，它會致使MySQL掃描大量不須要的行而后再拋棄掉。

數據模擬

那好，了解了問題的原理，那就要試著解決它了。涉及數據敏感性，咱們這邊模擬一下這種狀況，構造一些數據來作測試。

一、建立兩個表：員工表和部門表

1 /*部門表,存在則進行刪除*/

2 drop table if EXISTSdep;3 create tabledep(4 id int unsigned primary keyauto_increment,5 depno mediumint unsigned not null default 0,6 depname varchar(20) not null default"",7 memo varchar(200) not null default""8 );9

10 /*員工表,存在則進行刪除*/

11 drop table if EXISTSemp;12 create tableemp(13 id int unsigned primary keyauto_increment,14 empno mediumint unsigned not null default 0,15 empname varchar(20) not null default"",16 job varchar(9) not null default"",17 mgr mediumint unsigned not null default 0,18 hiredate datetime not null,19 sal decimal(7,2) not null,20 comn decimal(7,2) not null,21 depno mediumint unsigned not null default 0

22 );

二、建立兩個函數：生成隨機字符串和隨機編號

1 /*產生隨機字符串的函數*/

2 DELIMITER $3 drop FUNCTION if EXISTSrand_string;4 CREATE FUNCTION rand_string(n INT) RETURNS VARCHAR(255)5 BEGIN

6 DECLARE chars_str VARCHAR(100) DEFAULT 'abcdefghijklmlopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ';7 DECLARE return_str VARCHAR(255) DEFAULT '';8 DECLARE i INT DEFAULT 0;9 WHILE i

17

18 /*產生隨機部門編號的函數*/

19 DELIMITER $20 drop FUNCTION if EXISTSrand_num;21 CREATE FUNCTION rand_num() RETURNS INT(5)22 BEGIN

23 DECLARE i INT DEFAULT 0;24 SET i = FLOOR(100+RAND()*10);25 RETURNi;26 END$27 DELIMITER;

三、編寫存儲過程，模擬500W的員工數據

1 /*創建存儲過程：往emp表中插入數據*/

2 DELIMITER $3 drop PROCEDURE if EXISTSinsert_emp;4 CREATE PROCEDURE insert_emp(IN START INT(10),IN max_num INT(10))5 BEGIN

6 DECLARE i INT DEFAULT 0;7 /*set autocommit =0 把autocommit設置成0，把默認提交關閉*/

8 SET autocommit = 0;9 REPEAT10 SET i = i + 1;11 INSERT INTO emp(empno,empname,job,mgr,hiredate,sal,comn,depno) VALUES ((START+i),rand_string(6),'SALEMAN',0001,now(),2000,400,rand_num());12 UNTIL i =max_num13 ENDREPEAT;14 COMMIT;15 END$16 DELIMITER;17 /*插入500W條數據*/

18 call insert_emp(0,5000000);

四、編寫存儲過程，模擬120的部門數據

1 /*創建存儲過程：往dep表中插入數據*/

2 DELIMITER $3 drop PROCEDURE if EXISTSinsert_dept;4 CREATE PROCEDURE insert_dept(IN START INT(10),IN max_num INT(10))5 BEGIN

6 DECLARE i INT DEFAULT 0;7 SET autocommit = 0;8 REPEAT9 SET i = i+1;10 INSERT INTO dep( depno,depname,memo) VALUES((START+i),rand_string(10),rand_string(8));11 UNTIL i =max_num12 ENDREPEAT;13 COMMIT;14 END$15 DELIMITER;16 /*插入120條數據*/

17 call insert_dept(1,120);

五、創建關鍵字段的索引，這邊是跑完數據以后再建索引，會致使建索引耗時長，可是跑數據就會快一些。

1 /*創建關鍵字段的索引:排序、條件*/

2 CREATE INDEX idx_emp_id ONemp(id);3 CREATE INDEX idx_emp_depno ONemp(depno);4 CREATE INDEX idx_dep_depno ON dep(depno);

測試

測試數據

1 /*偏移量為100，取25*/

2 SELECTa.empno,a.empname,a.job,a.sal,b.depno,b.depname3 from emp a left join dep b on a.depno = b.depno order by a.id desc limit 100,25;4 /*偏移量為4800000，取25*/

5 SELECTa.empno,a.empname,a.job,a.sal,b.depno,b.depname6 from emp a left join dep b on a.depno = b.depno order by a.id desc limit 4800000,25;

執行結果

1 [SQL]

2 SELECTa.empno,a.empname,a.job,a.sal,b.depno,b.depname3 from emp a left join dep b on a.depno = b.depno order by a.id desc limit 100,25;4 受影響的行: 0

5 時間: 0.001s6 [SQL]

7 SELECTa.empno,a.empname,a.job,a.sal,b.depno,b.depname8 from emp a left join dep b on a.depno = b.depno order by a.id desc limit 4800000,25;9 受影響的行: 0

10 時間: 12.275s

由于掃描的數據多，因此這個明顯不是一個量級上的耗時。

解決方案

一、使用索引覆蓋+子查詢優化

由于咱們有主鍵id，而且在上面建了索引，因此能夠先在索引樹中找到開始位置的 id值，再根據找到的id值查詢行數據。

1 /*子查詢獲取偏移100條的位置的id，在這個位置上日后取25*/

2 SELECTa.empno,a.empname,a.job,a.sal,b.depno,b.depname3 from emp a left join dep b on a.depno =b.depno4 where a.id >= (select id from emp order by id limit 100,1)5 order by a.id limit 25;6

7 /*子查詢獲取偏移4800000條的位置的id，在這個位置上日后取25*/

8 SELECTa.empno,a.empname,a.job,a.sal,b.depno,b.depname9 from emp a left join dep b on a.depno =b.depno10 where a.id >= (select id from emp order by id limit 4800000,1)11 order by a.id limit 25;

執行結果

執行效率相比以前有大幅的提高：

1 [SQL]

2 SELECTa.empno,a.empname,a.job,a.sal,b.depno,b.depname3 from emp a left join dep b on a.depno =b.depno4 where a.id >= (select id from emp order by id limit 100,1)5 order by a.id limit 25;6 受影響的行: 0

7 時間: 0.106s8

9 [SQL]

10 SELECTa.empno,a.empname,a.job,a.sal,b.depno,b.depname11 from emp a left join dep b on a.depno =b.depno12 where a.id >= (select id from emp order by id limit 4800000,1)13 order by a.id limit 25;14 受影響的行: 0

15 時間: 1.541s

二、起始位置重定義

記住上次查找結果的主鍵位置，避免使用偏移量 offset

1 /*記住了上次的分頁的最后一條數據的id是100，這邊就直接跳過100，從101開始掃描表*/

2 SELECTa.id,a.empno,a.empname,a.job,a.sal,b.depno,b.depname3 from emp a left join dep b on a.depno =b.depno4 where a.id > 100 order by a.id limit 25;5

6 /*記住了上次的分頁的最后一條數據的id是4800000，這邊就直接跳過4800000，從4800001開始掃描表*/

7 SELECTa.id,a.empno,a.empname,a.job,a.sal,b.depno,b.depname8 from emp a left join dep b on a.depno =b.depno9 wherea.id > 4800000

10 order by a.id limit 25;

執行結果

1 [SQL]

2 SELECTa.id,a.empno,a.empname,a.job,a.sal,b.depno,b.depname3 from emp a left join dep b on a.depno =b.depno4 where a.id > 100 order by a.id limit 25;5 受影響的行: 0

6 時間: 0.001s7

8 [SQL]

9 SELECTa.id,a.empno,a.empname,a.job,a.sal,b.depno,b.depname10 from emp a left join dep b on a.depno =b.depno11 where a.id > 4800000

12 order by a.id limit 25;13 受影響的行: 0

14 時間: 0.000s

這個效率是最好的，不管怎么分頁，耗時基本都是一致的，由于他執行完條件以后，都只掃描了25條數據。

可是有個問題，只適合一頁一頁的分頁，這樣才能記住前一個分頁的最后Id。若是用戶跳著分頁就有問題了，好比剛剛刷完第25頁，立刻跳到35頁，數據就會不對。

這種的適合場景是相似百度搜索或者騰訊新聞那種滾輪往下拉，不斷拉取不斷加載的狀況。這種延遲加載會保證數據不會跳躍著獲取。

三、降級策略

看了網上一個阿里的dba同窗分享的方案：配置limit的偏移量和獲取數一個最大值，超過這個最大值，就返回空數據。

由于他以為超過這個值你已經不是在分頁了，而是在刷數據了，若是確認要找數據，應該輸入合適條件來縮小范圍，而不是一頁一頁分頁。

這個跟我同事的想法大體同樣：request的時候 若是offset大于某個數值就先返回一個4xx的錯誤。

小結：

當晚咱們應用上述第三個方案，對offset作一下限流，超過某個值，就返回空值。次日使用第一種和第二種配合使用的方案對程序和數據庫腳本進一步作了優化。

合理來講作任何功能都應該考慮極端狀況，設計容量都應該涵蓋極端邊界測試。

另外，該有的限流、降級也應該考慮進去。好比工具多線程調用，在短期頻率內8000次調用，可使用計數服務判斷并反饋用戶調用過于頻繁，直接給予斷掉。

哎，大意了啊，搞了半夜，QA同窗不講武德。不過這是很美好的經歷了。

總結

以上是生活随笔為你收集整理的mysql left 数学原理,MySQL全面瓦解21（番外）：一次深夜优化亿级数据分页的奇妙经历...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。