列表分頁接口怎麼設計提示詞（游標分頁與頁碼分頁、穩定排序、深分頁優化、篩選與索引配合）
設計列表、搜尋、資訊流類接口，或者翻到後面幾頁越來越慢、翻頁出現重複或漏數據時用：AI 根據前端交互和數據量在頁碼分頁與游標分頁之間選擇，設計穩定排序、游標編碼、篩選參數與對應的索引，並給出 SQL 與接口返回結構。
通用大模型 對話模型通用
你是一名後端工程師，擅長設計高性能的列表接口。請幫我設計分頁方案。 - 列表內容：[列表內容]（例：訂單列表、商品搜尋、動態資訊流） - 前端交互：[前端交互]（例：頁碼跳轉、下拉加載更多、上一頁下一頁） - 數據量與增長速度：[數據量]（例：單用戶最多 10 萬條，每天新增頻繁） - 篩選與排序需求：[篩選與排序]（例：按狀態篩選，按創建時間或金額排序） - 數據庫：[數據庫] - 表結構與現有索引： [粘貼表結構] 請輸出： 1. 方案選擇：頁碼分頁（偏移量）與游標分頁（基於上一頁最後一條記錄）的對比——跳頁能力、深分頁性能、數據頻繁新增時的重複與遺漏、總數統計的成本；結合我的前端交互給出推薦，可以組合使用。 2. 穩定排序：排序字段可能重複（如同一時間創建）時，追加唯一字段作為第二排序鍵，保證翻頁結果確定。 3. 游標設計（如果使用）：游標包含哪些字段、如何編碼成不透明的字符串、如何防止被篡改或校驗格式；排序方向切換時的處理；多字段排序時的比較條件寫法。 4. 頁碼分頁的優化（如果使用）：深分頁的問題與優化手段（如先查主鍵再回表、限制最大頁數）；總數統計的開銷與替代方案（例如只顯示「還有更多」或使用估算值）。 5. 參數設計：每頁數量的預設值與上限、篩選參數的命名與校驗、排序字段的白名單。 6. 索引：根據篩選和排序條件設計聯合索引，說明字段順序的理由。 7. 返回結構：數據列表、下一頁游標或總數、是否還有更多。 8. 給出完整的 SQL 和接口實現代碼。
高亮處換成你自己的內容：[列表內容]、[前端交互]、[數據量]、[篩選與排序]、[數據庫]、[粘貼表結構]
ChatGPT Plus 充值
已被複製 0 次
使用說明
怎麼填變量：[前端交互] 決定方案：需要「跳到第 37 頁」時只能用頁碼分頁；下拉加載更多、上一頁下一頁，用游標分頁更快也更準確。[表結構與現有索引] 要貼，分頁性能最終取決於索引能否覆蓋篩選和排序。
常見坑：
- 只按創建時間排序，同一秒內創建的記錄順序不確定，翻頁時會出現重複或漏掉。追加主鍵作為第二排序鍵。
- 資訊流使用偏移量分頁，用戶翻頁期間有新內容插入，下一頁就會出現上一頁已經看過的內容。
- 每次請求都統計總數，在大表上非常慢。很多場景下只需要知道「還有沒有下一頁」。
追問技巧：追問「列表需要同時支持按金額和按時間排序，游標該怎麼設計」，或「這個列表接口如何加緩存，數據更新後怎麼失效」。
示例輸出
示例，僅供參考（訂單列表，按創建時間倒序，游標分頁）
sql
-- 索引：等值篩選字段在前，排序字段在後
CREATE INDEX idx_orders_user_status_time ON orders (user_id, status, created_at DESC, id DESC);
-- 第一頁
SELECT id, order_no, amount, created_at FROM orders
WHERE user_id = ? AND status = ?
ORDER BY created_at DESC, id DESC
LIMIT 21; -- 多取 1 條，用於判斷是否還有下一頁
-- 下一頁：游標解碼得到上一頁最後一條的 (created_at, id)
SELECT id, order_no, amount, created_at FROM orders
WHERE user_id = ? AND status = ?
AND (created_at < ? OR (created_at = ? AND id < ?))
ORDER BY created_at DESC, id DESC
LIMIT 21;json
{ "items": ["……20 條……"], "nextCursor": "eyJ0IjoiMjAyNi0xMC0wN1QxMDowMDowMFoiLCJpZCI6OTg3fQ", "hasMore": true }同款作品
用這條提示詞做出來的作品；原作者會因此獲得積分
還沒有同款，來做第一個。
0 條評論
還沒有評論，來搶沙發～