NoSQL 與 MySQL 千億級分頁查詢性能深度辯論實錄：MongoDB vs MySQL 實戰對比

辯論背景

技術群內關於「千億級數據、按省分組、任意翻頁到第 100 萬頁」的 NoSQL (MongoDB) vs MySQL 性能對比討論實錄整理，提煉核心觀點與工程結論。

核心場景定義

• 數據量：13 億記錄（模擬全國人口）。
• 分組：32 個省份。
• 查詢：按省份篩選 → 按出生時間/年齡排序 → 任意深度分頁（如第 100 萬頁，每頁 50 條）。
• 要求：修改年齡後實時定位到新頁碼。

雙方核心觀點對比

關鍵技術共識（雙方最終一致）

1. 深度分頁必須用游標/Range 查詢，OFFSET/LIMIT 或 skip/limit 在千萬級偏移量下**任何數據庫都會全量掃描排序**，不可用。
2. 索引設計決定性能：(province, birth_date, id) 覆蓋查詢，MySQL/MongoDB 同理。
3. 千億級單表不可取：必須分片（MySQL 分庫分表 / MongoDB Sharding），按省份或哈希分片。
4. 實時修改定位新頁碼：應用層維護「排序鍵 → 頁碼」映射，或重新查詢游標，無銀彈。
5. 硬體資源是基礎：內存裝不下熱數據時，任何引擎都會回退到磁碟 IO，性能崩塌。

MySQL 實戰優化方案（針對該場景）

-- 1. 分表：按省份 32 張表 user_province_01 ... 32
-- 2. 索引
CREATE INDEX idx_prov_birth_id ON user_province_xx (birth_date, id);

-- 3. 游標分頁 API
-- 首頁
SELECT id, name, birth_date FROM user_province_13 WHERE birth_date >= '2000-01-01' ORDER BY birth_date, id LIMIT 50;
-- 後續頁（前端傳遞 last_birth_date, last_id）
SELECT id, name, birth_date FROM user_province_13 
WHERE birth_date > ? OR (birth_date = ? AND id > ?)
ORDER BY birth_date, id LIMIT 50;

-- 4. 年齡修改後重新定位：重新查詢該用戶 birth_date，作為新游標起點

MongoDB 實戰優化方案

-- 1. 分片：shard key {province: 1, birth_date: 1}
sh.shardCollection("pop.user", {province: 1, birth_date: 1})

-- 2. 索引
db.user.createIndex({province: 1, birth_date: 1, _id: 1})

-- 3. 游標分頁
db.user.find({province: 13, birth_date: {$gte: ISODate("2000-01-01")}})
       .sort({birth_date: 1, _id: 1})
       .limit(50)
-- 後續頁用 $gt 範圍查詢代替 skip

避坑總結

• 不要信「XXX 資料庫天生適合深度分頁」 — 物理限制無法突破，必須改業務交互模式（游標/無限滾動/搜索而非翻頁）。
• 不要為了「字段隨意加」選 MongoDB — 無 Schema 意味著應用層需承擔更嚴格的契約測試與文檔治理。
• 不要忽略運維代價 — MongoDB 分片集群均衡、Chunk 遷移、備份恢復比 MySQL 主從複雜得多。
• 選型原則：強一致性、複雜關聯、成熟運維 → MySQL；極高寫入吞吐、文檔結構多變、可接受最終一致 → MongoDB。

結語

辯論最終歸於理性：架構設計（分片、索引、游標分頁）遠比存儲引擎選擇重要。千億級業務在 MySQL 與 MongoDB 均可落地，關鍵在於團隊對該技術棧的掌控深度與運維體系成熟度。