成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

分頁查詢出現數據重復或丟失,你遇到過嗎?

數據庫 其他數據庫
如果是 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 - 分頁出現數據重復或丟失的問題,一文搞定!

責任編輯:武曉燕 來源: 鴨血粉絲Tang
相關推薦

2020-11-08 14:38:35

JavaScript代碼開發

2011-04-26 09:22:05

SQLite

2009-07-23 15:07:32

2018-04-25 10:57:00

AIX報錯vios

2021-12-26 14:32:11

緩存數據庫數據

2020-10-12 09:49:14

C++ 開發代碼

2021-08-29 18:36:17

MySQL技術面試題

2020-09-24 10:49:09

iOSiPadOSBug

2019-09-15 22:36:26

數據庫查詢日志檢索

2021-12-30 09:32:04

緩存數據庫數據

2024-03-18 08:14:07

SpringDAOAppConfig

2022-10-20 18:00:59

OCP模型參數

2018-03-26 09:39:06

大數據IT互聯網

2019-10-28 14:07:29

研發管理技術

2021-04-04 22:31:26

白帽子廠商漏洞

2017-07-14 09:29:45

AndroidWebview

2025-05-28 00:00:01

MySQL場景索引

2021-02-19 11:01:46

異步競態接口異步

2020-04-26 14:40:19

戴爾

2021-05-27 09:27:35

開發技能緩存
點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板: 一区二区免费在线 | 国产精品一级在线观看 | 色就干| 天天玩夜夜操 | 国产日韩欧美另类 | 欧美不卡一区二区 | 国产精品99久久久久久久久久久久 | 成人免费视频 | 国产视频1区 | 国产成人综合久久 | 久久综合av | 亚洲精品视频久久 | 不卡一区 | 一区二区日本 | 亚洲性在线 | 一级a爱片性色毛片免费 | 国产一区影院 | 国产视频一二三区 | 欧美精品一区二区免费 | 日韩av免费在线观看 | 一区二区三区精品视频 | 99成人 | 一级黄色片在线免费观看 | 国产精品视频网 | 免费特黄视频 | 久久综合一区二区三区 | 精品久久久久久久久久久久 | 日韩av免费在线电影 | 91欧美 | 国产精品国产成人国产三级 | 国产精品久久久久久av公交车 | 成人在线一区二区三区 | 黄视频网址 | 日韩久久久久久 | 久久精品二区亚洲w码 | 国产亚洲精品久久久优势 | 一区二区免费 | 青青草这里只有精品 | 色综合色综合色综合 | 国产精品成av人在线视午夜片 | 国产蜜臀97一区二区三区 |