MySQL 複雜查詢分頁優化：ID 預查詢 + 臨時表/Session 緩存方案

痛點：LIMIT m,n 在複雜條件下的效能崩潰

有索引時 LIMIT m,n 較快，但複雜條件（如 WHERE ... ORDER BY field1+field2）會導致 MySQL 全表掃描取出所有符合條件記錄再切片。數十萬資料量下，用戶翻閱尾頁會引發大量磁碟 I/O。

核心思路：模擬「存儲分頁」機制

一次性查詢符合條件的主鍵 ID 集合，後續分頁直接按 ID 列表精確取回，避免重複掃描。

步驟 1：預查詢 ID 集合

SELECT id FROM `$table` WHERE `$condition` ORDER BY `$field` LIMIT $max_pages*$count;

• 可限制最大回傳筆數（$max_pages * $count），防止記憶體暴增
• 若不加 LIMIT 需評估記憶體風險

步驟 2：ID 集合持久化（二選一）

步驟 3：分頁精確取回

SELECT * FROM `$table` WHERE id IN ($ids);  -- $ids 為逗號分隔的 ID 字串

主鍵查詢極快，徹底解決深分頁效能問題。

討論與延伸

• ASP Recordset 分頁將大量資料載入記憶體，失效機制不明確
• SQL Server 游標/預存程序分頁原理類似，但過期結果清理機制需自行設計
• 本方案為概念驗證，歡迎實測回饋優化細節（如臨時表清理策略、Session 髒資料處理）