分頁和替代解決方案

Question

假設我有一個有10000行的表格。一些用戶（例如網站）想要使用這張表格來處理某些條件和條件的情況。

變＃1 - 使用SQL限制，通常分頁
據我瞭解數據庫必須1）找到所有（）行滿足where條件，2）數據庫必須進行排序的所有（）發現的行，在步驟1中！並從這些發現的行3）它必須返回一些由限制和偏移量定義的集合。

變＃2 - 讀取所有ID列表結構
另一種解決方案是做了第一次查詢的條件，以獲得ID列表某些那裏的條件和秩序，並保存它。對於每個頁面，我們都會得到{..}中的id，並按客戶端列表排序的行（因爲數據庫將按未排序的順序返回行）。這個變體的優點不是要對每個頁面的所有行進行過濾和排序。缺點是需要保存相當長的名單。除了這個變體只有在數據不經常變化的情況下才能使用。

我對變體＃1的理解是否正確？是否在實踐中使用變體＃2或者它是不好的解決方案？

Answer 1

變體1是接近此的「正常」方式。在很多情況下，你會驚訝它的工作效果。這裏有一些原因：

• 看起來像複雜的處理實際上可能相當快，特別是通過審慎使用索引。 （例如，排序可能不是必需的。）
• 查詢的結果可能會在運行之間進行緩存。

第二種方法有一些缺點：

• 如果基礎數據的變化，ID可能不再有效。
• 整個結果集（根據ID）需要事先生成。這可能很昂貴。但我必須承認，如果查詢有order by，這可能不會比第一次運行Variant 1更昂貴。
• 所有ID都需要返回給應用程序。這是一個大殺手，特別是如果你可以有大量的ID被返回。
• 應用程序無法繼續處理，直到返回所有行，儘管可能有一些解決方法。

也就是說，在某些情況下，變體2可能是最好的解決方案。然而，更典型的解決方案是讓數據庫處理分頁。