MySQL深分頁優(yōu)化方式
MySQL深分頁優(yōu)化
MySQL中的深分頁問題通常是指當我們通過LIMIT
語句查詢數(shù)據(jù),尤其是在翻到較后面的頁碼時,性能會急劇下降。
例如,查詢第1000頁的數(shù)據(jù),每頁10條,系統(tǒng)需要跳過前9990條數(shù)據(jù),然后才能獲取到所需的記錄,這在大數(shù)據(jù)集上非常低效。
傳統(tǒng)的深分頁實現(xiàn)方法通常是使用OFFSET
和LIMIT
直接做分頁查詢:
SELECT * FROM table ORDER BY some_column LIMIT 9990, 10;
這會導(dǎo)致數(shù)據(jù)庫掃描大量不需要的行然后拋棄它們,才能獲取到真正需要的數(shù)據(jù)。
延遲關(guān)聯(lián)的工作方式
延遲關(guān)聯(lián)通過兩步查詢優(yōu)化性能:
- 快速定位:首先僅在索引上運行快速查詢,快速定位到需要的數(shù)據(jù)的位置。這個步驟不獲取所有字段,只獲取主鍵或者是用于排序的列。
- 精確獲取:然后根據(jù)第一步查詢獲得的主鍵(或少數(shù)幾個列),做第二步的查詢以精確獲取所有需要的數(shù)據(jù)字段。
示例:有 posts
表和 comments
表。
-- 查詢有特定標簽的文章的ID SELECT post_id INTO TEMPORARY TABLE temp_post_ids FROM posts WHERE tags LIKE '%特定標簽%'; -- 利用臨時表數(shù)據(jù)進行關(guān)聯(lián)查詢 SELECT p.*, c.* FROM temp_post_ids t JOIN posts p ON t.post_id = p.id LEFT JOIN comments c ON p.id = c.post_id;
為什么能提升性能
- 減少數(shù)據(jù)掃描量:第一步查詢只在索引上運行,大大減少了數(shù)據(jù)的掃描量。因為索引通常比完整的數(shù)據(jù)行要小很多,而且數(shù)據(jù)庫可以更有效地在索引上進行排序和分頁操作。
- 減少IO操作:只有在第二步查詢中才會獲取完整的數(shù)據(jù)行,這減少了數(shù)據(jù)庫的IO操作,尤其是當表中包含大量大型字段(如
TEXT
,BLOB
類型)時。 - 充分利用索引:通常,第一步的查詢能夠充分利用索引,使查詢效率最大化。
最大ID查詢法
使用最大ID查詢法,我們利用了數(shù)據(jù)庫中的ID通常是自增(或至少是有序的)這一性質(zhì)。
通過記錄上一次查詢返回的最后一條記錄的ID,下一次查詢時,我們只需要選擇ID大于這個值的記錄,這樣避免了掃描和跳過前面所有的記錄。
優(yōu)點:
- 性能提升:這種方法減少了數(shù)據(jù)庫的負載,尤其是對于大數(shù)據(jù)集。因為它只查詢需要的數(shù)據(jù),避免了大量的無用掃描。
- 可擴展性:隨著數(shù)據(jù)量的增加,傳統(tǒng)的
OFFSET
方法性能降低,而最大ID方法的性能下降不明顯,適合大數(shù)據(jù)量的場景。 - 簡單有效:實現(xiàn)簡單,但能顯著提高分頁查詢的性能。
缺點:
- 依賴有序的ID:這個方法的有效性依賴于有序的ID(比如自增ID)。如果數(shù)據(jù)庫表中沒有一個有序的、單調(diào)遞增的字段,這種方法就不適用。
- 不適合復(fù)雜排序需求:當查詢需要基于其他字段進行排序時,這種方法可能就不再適用。比如,如果需要基于時間或者其他非遞增字段進行分頁,最大ID方法就不能直接使用了。
- 數(shù)據(jù)刪除或更新的處理:如果數(shù)據(jù)表中的記錄會被刪除,那么這可能會導(dǎo)致某些ID被跳過,從而影響分頁的連續(xù)性。同樣,如果ID是可更新的,那么這種方法也會遇到問題。
- 非等距分頁:使用最大ID進行分頁時,如果數(shù)據(jù)表中存在大量的刪除操作,導(dǎo)致ID有較大的間隔,可能會出現(xiàn)每頁數(shù)據(jù)量不一致的情況。雖然通常這不是一個大問題,但在某些應(yīng)用場景中可能會影響用戶體驗。
- 首頁數(shù)據(jù)動態(tài)變化:如果你的應(yīng)用場景需要頻繁展示數(shù)據(jù)的最新狀態(tài),使用最大ID分頁法可能會導(dǎo)致最新添加的記錄不被即時顯示。例如,當用戶在瀏覽第二頁時,如果首頁有新數(shù)據(jù)添加,用戶回到首頁可能看不到這些新數(shù)據(jù),因為查詢的起始ID已經(jīng)改變。
- 不適用于隨機訪問:對于需要直接跳轉(zhuǎn)到指定頁面的場景(例如,用戶直接跳轉(zhuǎn)到第100頁),最大ID方法實現(xiàn)起來比較困難,因為你無法直接知道第100頁開始的ID是多少,除非你額外維護一個每頁開始ID的映射表。
總結(jié)
以上為個人經(jīng)驗,希望能給大家一個參考,也希望大家多多支持腳本之家。
相關(guān)文章
MySql數(shù)據(jù)庫基礎(chǔ)之分組查詢詳解
這篇文章主要介紹了mysql按照時間分組查詢的語句,非常實用,sql語句簡單易懂,對大家的學(xué)習(xí)或工作具有一定的參考借鑒價值,需要的朋友可以參考下2022-09-09MySQL為什么要避免大事務(wù)以及大事務(wù)解決的方法
這篇文章主要介紹了MySQL為什么要避免大事務(wù)以及大事務(wù)解決的方法,幫助大家更好的理解和學(xué)習(xí)MySQL,感興趣的朋友可以了解下2020-08-08MySQL8.0移除傳統(tǒng)的.frm文件原因及解讀
MySQL 8.0移除傳統(tǒng)的.frm文件,采用基于InnoDB的事務(wù)型數(shù)據(jù)字典,主要解決了元數(shù)據(jù)不一致、性能優(yōu)化、架構(gòu)簡化、增強功能支持、兼容性與升級問題,這一變革提高了數(shù)據(jù)庫的可靠性和性能,為未來的高級功能奠定了基礎(chǔ)2025-03-03DataGrip連接Mysql并創(chuàng)建數(shù)據(jù)庫的方法實現(xiàn)
本文主要介紹了DataGrip連接Mysql并創(chuàng)建數(shù)據(jù)庫的方法實現(xiàn),文中通過示例代碼介紹的非常詳細,具有一定的參考價值,感興趣的小伙伴們可以參考一下2022-02-02探討SQL利用INFORMATION_SCHEMA系統(tǒng)視圖如何獲取表的主外鍵信息
本篇文章是對SQL利用INFORMATION_SCHEMA系統(tǒng)視圖如何獲取表的主外鍵信息進行了詳細的分析介紹,需要的朋友參考下2013-06-06