不在分頁中使用offset和limit的原因是什么

這篇文章主要講解了“不在分頁中使用offset和limit的原因是什么”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“不在分頁中使用offset和limit的原因是什么”吧！

OFFSET和LIMIT有什么問題?

正如我們在上幾段中簡要探討的那樣，OFFSET和LIMIT非常適合于數(shù)據(jù)使用量很少甚至沒有的項目。

當(dāng)你的數(shù)據(jù)庫開始收集的數(shù)據(jù)超過了服務(wù)器在內(nèi)存中的存儲量時，問題就出現(xiàn)了，你仍然需要對這些數(shù)據(jù)進行高性能的分頁。

要做到這一點，數(shù)據(jù)庫需要在每次請求分頁時執(zhí)行一次低效的全表掃描(在此期間可能會發(fā)生插入和刪除，我們不希望數(shù)據(jù)過時!)。

這意味著，如果你有100.000.000個用戶，而你要求的OFFSET是50.000.000，那么它將需要獲取所有這些記錄(甚至不需要!)，將它們放在內(nèi)存中，然后才會得到在LIMIT中指定的20個結(jié)果。

因此，要在網(wǎng)站上顯示這樣的分頁：

50.000 to 50.020 of 100.000

首先需要獲取50.000行，看看這效率低下嗎?

你應(yīng)該使用什么

這是你應(yīng)該使用的：

這是基于游標(biāo)的分頁。

你應(yīng)該存儲最后接收到的主鍵(通常是一個ID)和Limit，而不是在本地存儲當(dāng)前offset和limit將其與每個請求一起傳遞，這樣查詢最終可能與此類似。

為什么?因為通過顯式傳遞最新的讀取行，你可以根據(jù)有效的索引鍵告訴數(shù)據(jù)庫確切從哪里開始搜索，而不必考慮該范圍之外的任何行。

以下面的比較為例：

針對我們的優(yōu)化版本：

接收到的記錄完全相同，但是第一個查詢花費了12.80秒，第二個查詢花費了0.01秒。你能體會到差異嗎?

注意事項

為了使游標(biāo)分頁能夠無縫地工作，你需要有一個獨特的、有順序的列(或列)，比如一個獨特的整數(shù)ID，在某些特定的情況下，這可能是一個問題。

和以往一樣，我的建議是一定要考慮每個表架構(gòu)的優(yōu)缺點，以及你需要在每個表中執(zhí)行哪種查詢。如果你需要在查詢中處理大量相關(guān)數(shù)據(jù)，Rick  James的“Lists article”文章可能會為你提供更深入的指導(dǎo)。

如果我們手中的問題與沒有主鍵有關(guān)，比如我們有一個多對多的關(guān)系表，傳統(tǒng)的OFFSET/LIMIT的方法在這些情況下總是可以使用的，然而這將重新引入潛在的較慢的查詢。因此，我建議在要分頁的表中使用自動遞增的主鍵，即使只是出于分頁的目的。

感謝各位的閱讀，以上就是“不在分頁中使用offset和limit的原因是什么”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對不在分頁中使用offset和limit的原因是什么這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關(guān)知識點的文章，歡迎關(guān)注！