01、問題背景

最近部分用戶反饋在 APP 上查詢自己名下訂單數(shù)據(jù)時(shí)，當(dāng)往下拉取數(shù)據(jù)的時(shí)候，列表上出現(xiàn)重復(fù)的訂單數(shù)據(jù)，經(jīng)過代碼排查，后端代碼是通過如下方式來實(shí)現(xiàn)數(shù)據(jù)的分頁查詢的。DoI28資訊網(wǎng)——每日最新資訊28at.com

limit offset, size order by create_time desc

一開始大家都不以為然，這么標(biāo)準(zhǔn)的寫法，怎么可能會(huì)出錯(cuò)！但經(jīng)過細(xì)致的分析，這種排序方式，在 app 端分頁查詢的時(shí)候，確實(shí)存在問題。DoI28資訊網(wǎng)——每日最新資訊28at.com

詳細(xì)的分析過程如下！DoI28資訊網(wǎng)——每日最新資訊28at.com

02、原因分析

首先我們初始化一張表，用于模擬訂單表查詢。DoI28資訊網(wǎng)——每日最新資訊28at.com

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ù)分析DoI28資訊網(wǎng)——每日最新資訊28at.com

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í)間倒序來查詢，結(jié)果如下：DoI28資訊網(wǎng)——每日最新資訊28at.com

-- 發(fā)起第一頁查詢select * from tb_order order by create_time desc limit 0,2;-- 第一頁查詢結(jié)果|order_id |   create_time       ||5        |  2023-03-03 12:00:05||4        |  2023-03-03 12:00:04|-- 發(fā)起第二頁查詢select * from tb_order order by create_time desc limit 2,2;-- 第二頁查詢結(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ù)問題。DoI28資訊網(wǎng)——每日最新資訊28at.com

但是當(dāng)訂單數(shù)據(jù)發(fā)生了變動(dòng)，比如在查詢的時(shí)候，突然新增了訂單數(shù)據(jù)，此時(shí)的查詢結(jié)果就完全不一樣了。DoI28資訊網(wǎng)——每日最新資訊28at.com

還是以上面為例，假設(shè)在第一次查詢的時(shí)候，突然新增了一條數(shù)據(jù)，看看結(jié)果如何。DoI28資訊網(wǎng)——每日最新資訊28at.com

-- 發(fā)起第一頁查詢select * from tb_order order by create_time desc limit 0,2;-- 第一頁查詢結(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ā)起第二頁查詢select * from tb_order order by create_time desc limit 2,2;-- 第二頁查詢結(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)在頁面上兩次，正常情況下只有一次！DoI28資訊網(wǎng)——每日最新資訊28at.com

圖片DoI28資訊網(wǎng)——每日最新資訊28at.com

上面說到的是新增一條數(shù)據(jù)，假設(shè)刪除某條數(shù)據(jù)，看看結(jié)果如何。DoI28資訊網(wǎng)——每日最新資訊28at.com

-- 發(fā)起第一頁查詢select * from tb_order order by create_time desc limit 0,2;-- 第一頁查詢結(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ā)起第二頁查詢select * from tb_order order by create_time desc limit 2,2;-- 第二頁查詢結(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ù)之后，頁面查詢結(jié)果直接到訂單【ID=2】了，直接跳過訂單【ID=3】了，也就是說訂單【ID=3】的數(shù)據(jù)展示，丟失了！DoI28資訊網(wǎng)——每日最新資訊28at.com

圖片DoI28資訊網(wǎng)——每日最新資訊28at.com

總結(jié)下來，結(jié)論如下！DoI28資訊網(wǎng)——每日最新資訊28at.com

• 當(dāng)新增某條數(shù)據(jù)之后，通過常規(guī)的分頁查詢，列表會(huì)出現(xiàn)數(shù)據(jù)重復(fù)的現(xiàn)象；
• 當(dāng)刪除某條數(shù)據(jù)之后，通過常規(guī)的分頁查詢，列表會(huì)出現(xiàn)數(shù)據(jù)丟失的現(xiàn)象；

那怎么解決以上的問題呢？辦法如下！DoI28資訊網(wǎng)——每日最新資訊28at.com

DoI28資訊網(wǎng)——每日最新資訊28at.com

03、解決方案

針對上面所說的分頁查詢方式，我們需要做一些調(diào)整，調(diào)整辦法如下：DoI28資訊網(wǎng)——每日最新資訊28at.com

• 第一步：當(dāng)查詢出當(dāng)頁的數(shù)據(jù)之后，記錄下本次拉取的最后一條數(shù)據(jù)的排序字段值；當(dāng)發(fā)起下一頁數(shù)據(jù)查詢的時(shí)候，帶上這個(gè)參數(shù)，服務(wù)端通過這個(gè)參數(shù)做過濾條件
• 第二步：排序字段值不能出現(xiàn)重復(fù)，比如創(chuàng)建時(shí)間不能出現(xiàn)重復(fù)

以上面的新增為例，詳細(xì)的實(shí)踐過程如下：DoI28資訊網(wǎng)——每日最新資訊28at.com

-- 發(fā)起第一頁查詢select * from tb_order order by create_time desc limit 0,2;-- 第一頁查詢結(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ā)起第二頁查詢，帶上第一頁查詢的最后一條數(shù)據(jù)的排序字段值select * from tb_order where create_time < '2023-03-03 12:00:04' order by create_time desc limit 0,2;-- 第二頁查詢結(jié)果|order_id |   create_time       ||3        |  2023-03-03 12:00:03||2        |  2023-03-03 12:00:02|

此時(shí)的查詢結(jié)果正常，符合預(yù)期效果！DoI28資訊網(wǎng)——每日最新資訊28at.com

同樣的，以上面的刪除為例，詳細(xì)的實(shí)踐過程如下：DoI28資訊網(wǎng)——每日最新資訊28at.com

-- 發(fā)起第一頁查詢select * from tb_order order by create_time desc limit 0,2;-- 第一頁查詢結(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ā)起第二頁查詢select * from tb_order where create_time < '2023-03-03 12:00:04' order by create_time desc limit 0,2;-- 第二頁查詢結(jié)果|order_id |   create_time       ||3        |  2023-03-03 12:00:03||2        |  2023-03-03 12:00:02|

查詢結(jié)果與預(yù)期一致，正常！DoI28資訊網(wǎng)——每日最新資訊28at.com

04、深入思考

• 選擇的排序字段值出現(xiàn)了重復(fù)，怎么辦？

在上面我們提到了，排序字段值不能出現(xiàn)重復(fù)的要求，但是現(xiàn)實(shí)的情況是，如果以訂單的創(chuàng)建時(shí)間來排序，當(dāng)同一秒多次下單的時(shí)候大概率會(huì)出現(xiàn)重復(fù)，這個(gè)時(shí)候只能在訂單表里面新增一個(gè)排序字段，設(shè)置全局唯一索引，內(nèi)容是以時(shí)間為基礎(chǔ)來生成，比如雪花算法，或者自己寫一個(gè)基于時(shí)間全局自增的算法，確保全局唯一，最重要的是值的長度必須固定，訂單主鍵 ID 的生成規(guī)則推薦采用此方式，利用主鍵 ID 來排序效率查詢會(huì)非常高！DoI28資訊網(wǎng)——每日最新資訊28at.com

• 當(dāng)出現(xiàn)多個(gè)排序字段時(shí)，如何處理？

如果是 app 端的查詢，不建議設(shè)計(jì)多字段排序，因?yàn)樵诙嘧侄闻判虻沫h(huán)境下，服務(wù)端在進(jìn)行多條件的過濾查詢時(shí)，可能會(huì)把有效的數(shù)據(jù)給過濾掉，如果無法避開，盡量將多個(gè)排序字段合并到一個(gè)排序字段上，保證數(shù)據(jù)的查詢符合預(yù)期。DoI28資訊網(wǎng)——每日最新資訊28at.com

本文鏈接：http://www.www897cc.com/showinfo-26-112722-0.html盤點(diǎn)分頁查詢中遇到的坑！

聲明：本網(wǎng)頁內(nèi)容旨在傳播知識(shí)，若有侵權(quán)等問題請及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。郵件：2376512515@qq.com

上一篇： 是什么導(dǎo)致了，寫入MySQL庫表時(shí)間不正確？—— 官網(wǎng)也有Bug！

下一篇： 架構(gòu)設(shè)計(jì)的簡單原則，你學(xué)會(huì)了嗎？