如果是 App 端的查詢，不建議設計多字段排序，因為在多字段排序的環境下，服務端在進行多條件的過濾查詢時，可能會把有效的數據給過濾掉，如果無法避開，盡量將多個排序字段合并到一個排序字段上，保證數據的查詢符合預期。
?一、問題背景
最近部分銷售人員反饋在 APP 上查詢自己名下客戶訂單數據時，當往下拉取數據的時候，列表上經常出現重復的訂單數據，經過排查，后端代碼是通過如下方式來實現數據的分頁查詢的。
limit offset, size order by create_time desc
經過細致的分析，這種排序方式，在 app 端分頁查詢的時候，確實存在問題。
詳細的分析過程如下！
二、原因分析
首先我們初始化一張表，用于模擬訂單表查詢。
CREATE TABLE `tb_order` (
`order_id` bigint(11) unsigned NOT NULL,
`create_time` datetime DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
然后初始化 5 條數據進去，方便數據分析
INSERT INTO `tb_order` (`order_id`, `create_time`) VALUES (1, '2023-03-03 12:00:01');
INSERT INTO `tb_order` (`order_id`, `create_time`) VALUES (2, '2023-03-03 12:00:02');
INSERT INTO `tb_order` (`order_id`, `create_time`) VALUES (3, '2023-03-03 12:00:03');
INSERT INTO `tb_order` (`order_id`, `create_time`) VALUES (4, '2023-03-03 12:00:04');
INSERT INTO `tb_order` (`order_id`, `create_time`) VALUES (5, '2023-03-03 12:00:05');
假設我們每次只查詢 2 條數據，并且按照時間倒序來查詢，結果如下：
-- 發起第一頁查詢
select * from tb_order order by create_time desc limit 0,2;
-- 第一頁查詢結果
|order_id | create_time |
|5 | 2023-03-03 12:00:05|
|4 | 2023-03-03 12:00:04|
-- 發起第二頁查詢
select * from tb_order order by create_time desc limit 2,2;
-- 第二頁查詢結果
|order_id | create_time |
|3 | 2023-03-03 12:00:03|
|2 | 2023-03-03 12:00:02|
當訂單數據沒有發生變動的時候，這種查詢方式是不會造成出現重復的數據問題。
但是當訂單數據發生了變動，比如在查詢的時候，突然新增了訂單數據，此時的查詢結果就完全不一樣了。
還是以上面為例，假設在第一次查詢的時候，突然新增了一條數據，看看結果如何。
-- 發起第一頁查詢
select * from tb_order order by create_time desc limit 0,2;
-- 第一頁查詢結果
|order_id | create_time |
|5 | 2023-03-03 12:00:05|
|4 | 2023-03-03 12:00:04|
-- 新增一條訂單數據
INSERT INTO `tb_order` (`order_id`, `create_time`) VALUES (6, '2023-03-03 12:00:06');
-- 發起第二頁查詢
select * from tb_order order by create_time desc limit 2,2;
-- 第二頁查詢結果
|order_id | create_time |
|4 | 2023-03-03 12:00:04|
|3 | 2023-03-03 12:00:03|
可以很明顯的發現，訂單ID=4的數據，出現在頁面上兩次，正常情況下只有一次！
上面說到的是新增一條數據，假設刪除某條數據，看看結果如何。
-- 發起第一頁查詢
select * from tb_order order by create_time desc limit 0,2;
-- 第一頁查詢結果
|order_id | create_time |
|5 | 2023-03-03 12:00:05|
|4 | 2023-03-03 12:00:04|
-- 刪除一條訂單數據
delete from tb_order where order_id = 4;
-- 發起第二頁查詢
select * from tb_order order by create_time desc limit 2,2;
-- 第二頁查詢結果
|order_id | create_time |
|2 | 2023-03-03 12:00:02|
|1 | 2023-03-03 12:00:01|
可以很明顯的發現，刪除訂單ID=4的數據之后，頁面查詢結果直接到訂單ID=2了，直接跳過訂單ID=3了，也就是說訂單ID=3的數據展示，丟失了！
總結下來，結論如下！
- 當新增某條數據之后，通過常規的分頁查詢，列表會出現數據重復的現象；
- 當刪除某條數據之后，通過常規的分頁查詢，列表會出現數據丟失的現象；
那怎么解決以上的問題呢？辦法如下！
三、解決方案
針對上面所說的分頁查詢方式，我們需要做一些調整，調整辦法如下：
- 第一步：當查詢出當頁的數據之后，記錄下本次拉取的最后一條數據的排序字段值；當發起下一頁數據查詢的時候，帶上這個參數，服務端通過這個參數做過濾條件
- 第二步：排序字段值不能出現重復
以上面的新增為例，詳細的實踐過程如下：
-- 發起第一頁查詢
select * from tb_order order by create_time desc limit 0,2;
-- 第一頁查詢結果
|order_id | create_time |
|5 | 2023-03-03 12:00:05|
|4 | 2023-03-03 12:00:04|
-- 新增一條訂單數據
INSERT INTO `tb_order` (`order_id`, `create_time`) VALUES (6, '2023-03-03 12:00:06');
-- 發起第二頁查詢，帶上第一頁查詢的最后一條數據的排序字段值
select * from tb_order where create_time < '2023-03-03 12:00:04' order by create_time desc limit 0,2;
-- 第二頁查詢結果
|order_id | create_time |
|3 | 2023-03-03 12:00:03|
|2 | 2023-03-03 12:00:02|
此時的查詢結果正常，符合預期效果！
同樣的，以上面的刪除為例，詳細的實踐過程如下：
-- 發起第一頁查詢
select * from tb_order order by create_time desc limit 0,2;
-- 第一頁查詢結果
|order_id | create_time |
|5 | 2023-03-03 12:00:05|
|4 | 2023-03-03 12:00:04|
-- 刪除一條訂單數據
delete from tb_order where order_id = 4;
-- 發起第二頁查詢
select * from tb_order where create_time < '2023-03-03 12:00:04' order by create_time desc limit 0,2;
-- 第二頁查詢結果
|order_id | create_time |
|3 | 2023-03-03 12:00:03|
|2 | 2023-03-03 12:00:02|
查詢結果與預期一致，正常！
四、深入思考
- 選擇的排序字段值出現了重復，怎么辦？
在上面我們提到了，排序字段值不能出現重復的要求，但是現實的情況是，如果以訂單的創建時間來排序，當同一秒多次下單的時候大概率會出現重復，這個時候只能在訂單表里面新增一個排序字段，設置全局唯一索引，內容是以時間為基礎來生成，比如雪花算法，或者自己寫一個基于時間全局自增的算法，確保全局唯一，最重要的是值的長度必須固定，訂單主鍵 ID 的生成規則推薦采用此方式，利用主鍵 ID 來排序效率查詢會非常高！
- 當出現多個排序字段時，如何處理？
如果是 app 端的查詢，不建議設計多字段排序，因為在多字段排序的環境下，服務端在進行多條件的過濾查詢時，可能會把有效的數據給過濾掉，如果無法避開，盡量將多個排序字段合并到一個排序字段上，保證數據的查詢符合預期。
五、小結
本文主要圍繞 app 端分頁查詢出現數據重復或丟失的問題，進行一次復盤總結，如果有描述不對的地方，歡迎網友留言指出！
六、參考
1、知乎 - HQGDD - 分頁出現數據重復或丟失的問題，一文搞定！
