JavaScript 混淆及反混淆代碼工具
介紹在我們開始學習反混淆之前，我們首先要了解一下代碼混淆。如果不了解代碼是如何混淆的，我們可能無法成功對代碼進行反混淆，尤其是使用自定義混淆器對其進行混淆時。什么是混
最近部分用戶反饋在 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 端的查詢，不建議設計多字段排序，因為在多字段排序的環境下，服務端在進行多條件的過濾查詢時，可能會把有效的數據給過濾掉，如果無法避開，盡量將多個排序字段合并到一個排序字段上，保證數據的查詢符合預期。
本文鏈接：http://m.www897cc.com/showinfo-26-112722-0.html盤點分頁查詢中遇到的坑！
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： 是什么導致了，寫入MySQL庫表時間不正確？—— 官網也有Bug！
下一篇： 架構設計的簡單原則，你學會了嗎？
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號