前言
大家好,我是撿田螺的小男孩。
我們日常做分頁需求時,一般會用limit實現,但是當偏移量特別大的時候,查詢效率就變得低下。本文將分4個方案,討論如何優化MySQL百萬數據的深分頁問題,並附上最近優化生產慢SQL的實戰案例。
- 公衆號:撿田螺的小男孩
limit深分頁爲什麼會變慢?
先看下錶結構哈:
CREATE TABLE account (
id int(11) NOT NULL AUTO_INCREMENT COMMENT '主鍵Id',
name varchar(255) DEFAULT NULL COMMENT '賬戶名',
balance int(11) DEFAULT NULL COMMENT '餘額',
create_time datetime NOT NULL COMMENT '創建時間',
update_time datetime NOT NULL ON UPDATE CURRENT_TIMESTAMP COMMENT '更新時間',
PRIMARY KEY (id),
KEY idx_name (name),
KEY idx_update_time (update_time) //索引
) ENGINE=InnoDB AUTO_INCREMENT=1570068 DEFAULT CHARSET=utf8 ROW_FORMAT=REDUNDANT COMMENT='賬戶表';
複製代碼
假設深分頁的執行SQL如下:
select id,name,balance from account where update_time> '2020-09-19' limit 100000,10;
複製代碼
這個SQL的執行時間如下:
執行完需要0.742秒,深分頁爲什麼會變慢呢?如果換成 limit 0,10
,只需要0.006秒哦
我們先來看下這個SQL的執行流程:
- 通過普通二級索引樹idx_update_time,過濾update_time條件,找到滿足條件的記錄ID。
- 通過ID,回到主鍵索引樹,找到滿足記錄的行,然後取出展示的列(回表)
- 掃描滿足條件的100010行,然後扔掉前100000行,返回。
SQL的執行流程
執行計劃如下:
SQL變慢原因有兩個:
- limit語句會先掃描offset+n行,然後再丟棄掉前offset行,返回後n行數據。也就是說
limit 100000,10
,就會掃描100010行,而limit 0,10
,只掃描10行。 limit 100000,10
掃描更多的行數,也意味着回表更多的次數。
通過子查詢優化
因爲以上的SQL,回表了100010次,實際上,我們只需要10條數據,也就是我們只需要10次回表其實就夠了。因此,我們可以通過減少回表次數來優化。
回顧B+ 樹結構
那麼,如何減少回表次數呢?我們先來複習下B+樹索引結構哈~
InnoDB中,索引分主鍵索引(聚簇索引)和二級索引
- 主鍵索引,葉子節點存放的是整行數據
- 二級索引,葉子節點存放的是主鍵的值。
把條件轉移到主鍵索引樹
如果我們把查詢條件,轉移回到主鍵索引樹,那就不就可以減少回表次數啦。轉移到主鍵索引樹查詢的話,查詢條件得改爲主鍵id
了,之前SQL的update_time
這些條件咋辦呢?抽到子查詢那裏嘛~
子查詢那裏怎麼抽的呢?因爲二級索引葉子節點是有主鍵ID的,所以我們直接根據update_time
來查主鍵ID即可,同時我們把 limit 100000
的條件,也轉移到子查詢,完整SQL如下:
select id,name,balance FROM account where id >= (select a.id from account a where a.update_time >= '2020-09-19' limit 100000, 1) LIMIT 10;
複製代碼
查詢效果一樣的,執行時間只需要0.038秒!
我們來看下執行計劃
由執行計劃得知,子查詢 table a查詢是用到了idx_update_time
索引。首先在索引上拿到了聚集索引的主鍵ID,省去了回表操作,然後第二查詢直接根據第一個查詢的 ID往後再去查10個就可以了!
因此,這個方案是可以的~
INNER JOIN 延遲關聯
延遲關聯的優化思路,跟子查詢的優化思路其實是一樣的:都是把條件轉移到主鍵索引樹,然後減少回表。不同點是,延遲關聯使用了inner join代替子查詢。
優化後的SQL如下:
SELECT acct1.id,acct1.name,acct1.balance FROM account acct1 INNER JOIN (SELECT a.id FROM account a WHERE a.update_time >= '2020-09-19' ORDER BY a.update_time LIMIT 100000, 10) AS acct2 on acct1.id= acct2.id;
複製代碼
查詢效果也是槓桿的,只需要0.034秒
執行計劃如下:
查詢思路就是,先通過idx_update_time
二級索引樹查詢到滿足條件的主鍵ID,再與原表通過主鍵ID內連接,這樣後面直接走了主鍵索引了,同時也減少了回表。
標籤記錄法
limit 深分頁問題的本質原因就是:偏移量(offset)越大,mysql就會掃描越多的行,然後再拋棄掉。這樣就導致查詢性能的下降。
其實我們可以採用標籤記錄法,就是標記一下上次查詢到哪一條了,下次再來查的時候,從該條開始往下掃描。就好像看書一樣,上次看到哪裏了,你就摺疊一下或者夾個書籤,下次來看的時候,直接就翻到啦。
假設上一次記錄到100000,則SQL可以修改爲:
select id,name,balance FROM account where id > 100000 order by id limit 10;
複製代碼
這樣的話,後面無論翻多少頁,性能都會不錯的,因爲命中了id
索引。但是你,這種方式有侷限性:需要一種類似連續自增的字段。
使用between...and...
很多時候,可以將limit
查詢轉換爲已知位置的查詢,這樣MySQL通過範圍掃描between...and
,就能獲得到對應的結果。
如果知道邊界值爲100000,100010後,就可以這樣優化:
select id,name,balance FROM account where id between 100000 and 100010 order by id desc;
複製代碼
手把手實戰案例
我們一起來看一個實戰案例哈。假設現在有表結構如下,並且有200萬數據.
CREATE TABLE account (
id varchar(32) COLLATE utf8_bin NOT NULL COMMENT '主鍵',
account_no varchar(64) COLLATE utf8_bin NOT NULL DEFAULT '' COMMENT '賬號'
amount decimal(20,2) DEFAULT NULL COMMENT '金額'
type varchar(10) COLLATE utf8_bin DEFAULT NULL COMMENT '類型A,B'
create_time datetime DEFAULT NULL COMMENT '創建時間',
update_time datetime DEFAULT NULL COMMENT '更新時間',
PRIMARY KEY (id),
KEY `idx_account_no` (account_no),
KEY `idx_create_time` (create_time)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin COMMENT='賬戶表'
複製代碼
業務需求是這樣:獲取最2021年的A類型賬戶數據,上報到大數據平臺。
一般思路的實現方式
很多夥伴接到這麼一個需求,會直接這麼實現了:
//查詢上報總數量
Integer total = accountDAO.countAccount();
//查詢上報總數量對應的SQL
<select id ='countAccount' resultType="java.lang.Integer">
seelct count(1)
from account
where create_time >='2021-01-01 00:00:00'
and type ='A'
</select>
//計算頁數
int pageNo = total % pageSize == 0 ? total / pageSize : (total / pageSize + 1);
//分頁查詢,上報
for(int i = 0; i < pageNo; i++){
List<AcctountPO> list = accountDAO.listAccountByPage(startRow,pageSize);
startRow = (pageNo-1)*pageSize;
//上報大數據
postBigData(list);
}
//分頁查詢SQL(可能存在limit深分頁問題,因爲account表數據量幾百萬)
<select id ='listAccountByPage' >
seelct *
from account
where create_time >='2021-01-01 00:00:00'
and type ='A'
limit #{startRow},#{pageSize}
</select>
複製代碼
實戰優化方案
以上的實現方案,會存在limit深分頁問題,因爲account表數據量幾百萬。那怎麼優化呢?
其實可以使用標籤記錄法,有些夥伴可能會有疑惑,id主鍵不是連續的呀,真的可以使用標籤記錄?
當然可以,id不是連續,我們可以通過order by
讓它連續嘛。優化方案如下:
//查詢最小ID
String lastId = accountDAO.queryMinId();
//查詢最大ID對應的SQL
<select id="queryMinId" returnType=“java.lang.String”>
select MIN(id)
from account
where create_time >='2021-01-01 00:00:00'
and type ='A'
</select>
//一頁的條數
Integer pageSize = 100;
List<AcctountPO> list ;
do{
list = listAccountByPage(lastId,pageSize);
//標籤記錄法,記錄上次查詢過的Id
lastId = list.get(list,size()-1).getId();
//上報大數據
postBigData(list);
}while(CollectionUtils.isNotEmpty(list));
<select id ="listAccountByPage">
select *
from account
where create_time >='2021-01-01 00:00:00'
and id > #{lastId}
and type ='A'
order by id asc
limit #{pageSize}
</select>
作者:撿田螺的小男孩
鏈接:https://juejin.cn/post/7012016858379321358
來源:掘金
著作權歸作者所有。商業轉載請聯繫作者獲得授權,非商業轉載請註明出處。