1.2 查詢條件設計
二、技術方案
2.2 mysql + es架構
三、 db規範
產品設計不合理是導致深度分頁查詢的乙個重要原因，比如下圖所示的深度隨機跳頁設計方案，如果沒有特殊原因，正常情況下應避免使用。一方面，隨機跳頁實際意義有多大有待考究；另一方面，隨機性會加大後端的難度，如果隨機跳頁的頁碼很大，有可能導致查詢超時，甚至異常，反而影響產品的穩定性以及使用者體驗。
滾動分頁方案的特點是連續，分頁都是連續的，避免了隨機跳頁以及深度分頁，常用於移動端等支援手觸裝置上。
分頁查詢條件的設計，歸根結底就兩點：控制資料量，避免資料過大；降低複雜度，避免巢狀等過於複雜查詢；
方案說明：將k頁設為一組，每次從資料庫查詢時批量查詢（需要攜帶資料的最大id），然後將資料快取，同組的其它分頁查詢時，直接從快取查詢即可，如上圖所示。
問題：頁深有限制，m+n最大為1萬。頁數越深，占用記憶體越大，可能導致超時、oom等問題（每個分片的資料先查詢出m+n，然後再聚合）。
適用於非實時性場景，比如資料導、遷移等。
任何新建立的表，主鍵都為無符號整型且自增，確保db效能。
create
table
`order`(
`id`
bigint(20
)unsigned
notnull
auto_increment
comment
'主鍵id'
,`create_time`
datetime
notnull
default
current_timestamp
comment
'建立時間'
,`update_time`
datetime
notnull
default
current_timestamp
comment
'更新時間',.
..primary
key(
`id`),
)engine
=innodb
auto_increment=0
default
charset
=utf8mb4 comment
='訂單表'
;
1. 上億資料怎麼玩深度分頁？
訂單系統設計 訂單號設計
三 因子分表法 唯一性 必要 每個訂單號全域性唯一代表乙個訂單 安全性 必要 訂單號不能透露訂單量 運營規模等業務資訊 資料安全性 高效能 訂單號的建立成本越低越好 擴充套件性 能夠較好的支撐後續業務發展變大帶來的分庫分表 訂單長度擴充套件等場景 不安全 訂單號能夠反映出系統的訂單量，存在業務資料外...
訂單系統架構設計
高併發下單主要包括以下幾個方面 分庫分表 多應用例項全域性唯一訂單號 資料庫連線 買家查詢訂單 賣家查詢訂單 擴容問題 業務拆分 一 分庫分表 隨著訂單量的增長，資料庫的發展主要經歷以下幾個步驟 1主 1從架構 雙主 多從架構，讀寫分離 表分割槽，提高併發 分表，提高併發 master更換ssd 分...
訂單系統訂單表設計方案
一年前，在上一家公司接手了乙個含有訂單系統的專案，業務並不複雜，但是當時令我比較困惑的是訂單表的設計。困惑的點主要是隨著訂單量增加，單錶的儲存能力將達到瓶頸，必然要採用分表的方案，那麼按照什麼維度拆分合適呢？分表之後帶來的最大的挑戰是訂單查詢。如果以使用者為中心，採用userid取模，可以很方便的處...