MYSQL深度分页的常见优化方案
1、分頁查詢:一般寫法
一個比較常見的寫法
SELECT * FROM tableName where kid=1342 and type=1 order id asc limit 149420, 20;該SQL是一個經典的排序+分頁查詢
order by col limit N,M
MySQL 執行此類SQL時需要先掃描到N行,然后再去取M行。對于此類操作,獲取前面少數幾行數據會很快,但是隨著掃描的記錄數越多,SQL的性能就會越差,因為N的值越大,MySQL需要掃描越多的數據來定位到具體的N行,這樣耗費大量的 IO 成本和時間成本。
舉例說明
-- 表名:user -- 主鍵:id -- 索引:key idx_uid_type(uid, type) select * from user where uid =3 and type=1 order by id desc 8,2;MySQL 是如何執行上面的sql 的? 對于Innodb表,系統是根據 idx_uid_type二級索引里面包含的主鍵去查找對應的行,也就是會通過主鍵在進行一次回表查詢。
對于百萬千萬級別的數據而言,索引大小可能和數據大小相差無幾,cache在內存中的索引數量有限,而且二級索引和數據葉子節點不在同一個物理塊兒上存儲,二級索引與主鍵的相對無序映射關系,也會帶來大量的隨機IO請求,N值越大越需要遍歷大量索引頁和數據葉,需要耗費的時間就越久。
我們來思考一個問題,是否需要完全遍歷“無效的數據”?如果我們需要limit 8,2;我們跳過前面8行無關的數據頁遍歷,可以直接通過索引定位到第9,第10行,這樣操作是不是更快了?
2、分頁查詢:延遲關聯查詢
核心思思:通過使用覆蓋索引查詢返回需要的主鍵,再根據主鍵關聯原表獲得需要的數據,而不是通過二級索引獲取主鍵,再通過主鍵去遍歷數據頁(回表)。
SELECT a.id as id, clientid, adminid, kdtid, type, token, createdtime, updatetime, isvalid, version FROM t1 a, (SELECT id FROM t1 WHERE 1 and client_id = 'xxx' and is_valid= '1' order by kdt_id asc limit 267100,100 ) b WHERE a.id = b.id;上述SQL中的子查詢只取主鍵id,可避免通過二級索引中的主鍵去回表查詢,這樣性能會快一些。
像上述案例,當offset變得超級大時,會引發一個問題,它有一個專門的術語,叫深度分頁。
深度分頁問題,是個很惡心的問題,其惡心之處,在于這個問題,它其實無解。目前不管是mysql還是es都沒有很好的方法去解決這個問題。只能通過限制查詢數量或分批獲取的方式進行規避。
3、分頁查詢:基于上次最新主鍵查詢
核心思想:通過主鍵索引,每次定位到id在哪,然后往后遍歷N個數據,這樣不管是多少數據,查詢性能都很穩定。將所有數據根據主鍵id進行排序,然后分批次取,將當前批次的最大id作為下次篩選的條件進行查詢。
針對上面的延遲關聯查詢案例,我們使用基于上次最新主鍵查詢來進行優化,如下:
SELECT * FROM t1 where clientid='xxxxx' and isvalid=1 and id<47399727 order by id desc LIMIT 100;一般情況下該方式有如下兩步:
首先,要獲取復合條件的記錄的最大id和最小id(默認id是主鍵)
其次,根據id大于最小值或者小于最大值 進行遍歷。
select xx,xx from t where kid=2333 and type=1 and id >=min_id order by id asc limit 100; select xx,xx from t where kid=2333 and type=1 and id <=max_id order by id desc limit 100;4、小結
從上面的案例來講,基于上次最新主鍵查詢的方式直接定位到主鍵起始位點,然后過濾所需要的數據, 相對比延遲關聯查詢的方式,其查詢速度更快些,查找數據的時候少了二級索引掃描。
當遇到深度分頁的問題,多思考其原始需求,大部分時候是不應該出現深度分頁的場景的,必要時多去影響產品經理或需求方。
總結
以上是生活随笔為你收集整理的MYSQL深度分页的常见优化方案的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 如何让学习成为一种乐趣!
- 下一篇: 数据库SQL综合分析题