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