不再需要擔心數據庫性能優化的日子已經一去不復返了。

隨著時代的進步，每一個新的創業者都想打造下一個Facebook，再加上收集每一個可能的數據點以提供更好的機器學習預測的心態，作為開發者，我們需要準備好我們的API，比以往任何時候都要好，以提供可靠而高效的終端，應該能夠在海量數據中游刃有余。

如果你做過一段時間的后臺或者數據庫架構，你可能已經做過分頁查詢了，比如這樣。

對吧?

但是，如果你確實建立了這樣的分頁，我很抱歉的跟你說，你已經做錯了。

你不同意我的觀點?你不需要。Slack、Shopify和Mixmax都在用我們今天要講的這個概念來分頁他們的API。

我想請你說出一個沒有處理過分頁OFFSET和LIMIT的后端開發人員，對于MVP和低數據列表中的分頁，它“有效”。

今天我們要討論的是被廣泛使用的(錯誤的)實現方式存在哪些問題，以及如何實現高性能的分頁。

OFFSET和LIMIT有什么問題?

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

當你的數據庫開始收集的數據超過了服務器在內存中的存儲量時，問題就出現了，你仍然需要對這些數據進行高性能的分頁。

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

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

因此，要在網站上顯示這樣的分頁：

50.000 to 50.020 of 100.000 

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

你應該使用什么

這是你應該使用的：

這是基于游標的分頁。

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

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

以下面的比較為例：

針對我們的優化版本：

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

注意事項

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

和以往一樣，我的建議是一定要考慮每個表架構的優缺點，以及你需要在每個表中執行哪種查詢。如果你需要在查詢中處理大量相關數據，Rick James的“Lists article”文章可能會為你提供更深入的指導。

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

總結

這其中最主要的啟示應該是，無論你的查詢是用1k行還是用1M行，都要時刻檢查你的查詢性能如何。可擴展性是極其重要的，如果從一開始就能正確地實施，肯定可以避免未來許多頭痛的問題。

哦。而且，請不要忘記學習索引并explain queries。

如果你正在尋找如何在ElasticSearch上實現光標分頁，請隨時查看文章ElasticSearch--你應該這樣分頁你的結果。

ElasticSearch--你應該這樣分頁你的結果：

https://medium.com/@tmateus/elasticsearch-this-is-how-you-should-paginate-your-results-5d1c71bfe060