Meta翻頁方案被自家工程師吐槽：10億數據時偏移量分頁栽了

一個分頁接口在10萬用戶時穩如老狗，1000萬用戶時開始抽風，10億用戶時直接變成災難片。這不是壓力測試的假設場景，是Meta工程師在2023年內部技術分享里掏出的真家伙。

他們當時在給Reels做無限滾動，用的就是最經典的偏移量分頁（offset pagination）。方案簡單到新手都能寫：告訴數據庫"跳過前N條，給我接下來的20條"。SQL里就是LIMIT 20 OFFSET 184000這種寫法，前端只管累加數字就行。

問題出在N變大的時候。

MySQL的B+樹索引為了找到第184000條記錄，得從頭開始數。跳過10條和跳過100萬條，成本完全不是一個量級。Meta的監控顯示，深度分頁查詢的響應時間呈指數級爬升，到后面用戶手指都滑累了，數據還沒回來。

更隱蔽的是"漏項"bug。用戶正在刷第2頁時，第1頁某個視頻被作者刪了。整個列表往前擠了一位，第2頁的第一條就變成了剛才第1頁的最后一條。用戶會看到重復內容，卻永遠錯過被擠掉的那條。

這種數據漂移在UGC平臺是常態。Twitter早年也踩過這個坑，用戶時間線里偶爾會出現"這條推文已刪除"的占位符，就是偏移量分頁的補丁方案。

游標分頁：用位置錨點替代數學計算

游標分頁（cursor pagination）換了個思路。不再說"給我第幾頁"，而是說"從這條記錄之后，再給我20條"。

游標通常是對排序字段的編碼。按時間倒序就用最后一條的時間戳，按熱度排就用熱度分數。客戶端保存這個游標，下次請求原樣帶回。

數據庫層面變成了范圍查詢：WHERE created_at < '2024-03-15T09:23:11Z' LIMIT 20。B+樹索引直接定位到起點，時間復雜度從O(N)降到O(log N)。Meta切到游標后，深度分頁的P99延遲從秒級壓到了毫秒級。

數據漂移問題也迎刃而解。刪除操作不影響游標指向的錨點位置，用戶不會看到重復，也不會漏掉內容。Instagram的Reels團隊把這個方案寫進了內部最佳實踐文檔。

但游標不是萬能藥。

它犧牲了兩個偏移量分頁的天然優勢：隨機跳轉和總數統計。用戶沒法直接跳到"第50頁"，因為游標是單向鏈表，沒有頁碼概念。想顯示"共1283條結果"也得額外掃全表，在大數據量下成本極高。

這就是為什么電商網站的商品列表仍用偏移量——用戶需要知道"第3頁/共89頁"，需要直接點最后一頁看最早的商品。社交平臺的無限滾動沒有這些需求，游標就是更優解。

技術選型的隱藏成本：團隊認知債

一個常被忽略的事實：游標分頁的前端實現更復雜。偏移量時代，前端只管維護一個數字；游標時代，每個響應都可能攜帶不同的下一頁游標，得小心處理緩存和錯誤重試。

Netflix在2018年的技術博客中提到，他們遷移到游標分頁時，前端團隊花了整整一個季度處理邊界情況。比如用戶快速滑動導致多個并發請求，返回的游標順序可能錯亂，需要客戶端做去重和排序。

還有一個陷阱是游標失效。如果排序字段被更新——比如一條推文的點贊數變了，它在按熱度排序的列表里位置移動，舊的游標就可能指向錯誤的數據區間。Twitter的解決方案是游標里同時嵌入多個字段：熱度分數+時間戳+唯一ID，形成復合錨點。

這種復雜度解釋了為什么中小團隊往往明知偏移量有坑，還是繼續用。技術債分兩種：能測出來的性能債，和藏在代碼里的認知債。后者更難還。

混合方案：在用戶體驗和技術現實之間找平衡

現實很少非黑即白。GitHub的Issues列表是個典型混合案例：默認用游標做無限滾動，但如果你手動修改URL里的page=5參數，它也能用偏移量跳轉到指定位置。

這種"游標為主、偏移量為輔"的雙軌制，本質是區分用戶意圖。隨便刷刷的人用游標，有明確目標的人用偏移量。代價是維護兩套分頁邏輯，測試覆蓋要翻倍。

更激進的方案是"虛擬偏移量"。服務端維護一個映射表，把頁碼數字翻譯成游標。用戶看到的還是"第5頁"，實際走的是游標查詢。Shopify在2022年分享過類似實現，缺點是映射表本身成為新的瓶頸，需要緩存和分片策略。

國內大廠的做法更務實。抖音的推薦流純用游標，因為算法排序本身就不支持跳轉；小紅書的搜索結果用偏移量，因為用戶確實會點"下一頁"翻很多頁。沒有銀彈，只有場景。

回到Meta那個內部分享。工程師最后展示的監控曲線里，游標分頁的CPU使用率下降了67%，但代碼復雜度指標上升了40%。他們在幻燈片角落放了行小字："遷移成本被低估了，如果重來，我們會更早做。"

你的項目現在用哪種分頁？有沒有算過深度查詢的P99延遲？