分頁數據，必須有一個更好的辦法

我讀過像10左右的「教程」，並且它們都涉及同一件事：分頁數據，必須有一個更好的辦法

拉動數據計數設置
拉相關數據集（LIMIT，OFFSET）

IE：

SELECT COUNT(*) 
    FROM table 
WHERE something = ? 

SELECT * 
    FROM table 
WHERE something =? 
LIMIT ? offset ?`

兩個非常相似的疑問，不是嗎？必須有一個更好的方法來做到這一點，我的數據集有600,000多行並且已經很慢（結果是由30個以上的子句決定的，並且因用戶而異，但當然有適當的索引）。

來源

2010-06-17 Mohamed Ikal Al-Jabir

當然，你不希望加載所有的東西和分頁，例如用JavaScript，對吧？限制？偏移？'是一種很好的解決方案，可以減少傳輸的數據... – ShinTakezou 2010-06-17 16:17:23

有沒有方案可以用來將數據分解成更小的子集？ – 2010-06-17 17:19:04

使用統計數據計算估計值。這會爲你提供幫助，而且不會給你太多的開銷。

見http://wiki.postgresql.org/wiki/Count_estimate

來源

2010-06-17 16:21:34

我已經做了更多的獨立研究，即使MySQL的方式運行一個單獨的計數。原來，無論我們被搞砸了！（http://archives.postgresql.org/pgsql-performance/2006-12/msg00202.php）我打算將總＃緩存爲2小時更新。 – 2010-06-17 16:36:44

或者使用額外的表來存儲特定查詢的COUNT結果。觸發器將完成這項工作，以保持所有內容的同步。 – 2010-06-17 16:41:21

不幸的是，要得到確切數量，因爲它是在查詢的時刻，PostgreSQL有要經過符合標準，看看他們是否對您的交易可見的所有行。但是您可能不需要精確計算，因爲只要將結果發送給用戶，結果就會過時。所以有一些事情，你可以嘗試：

緩存後續查詢計數所以成本僅第一頁（可能沒有太大的幫助，大多數人只看第一頁反正）
如果查詢映射良好，則使用專門的倒排索引搜索引擎進行搜索。 Lucene/Solr是一個不錯的選擇。
如果有時候讓計數瘋狂地關閉不成問題，請使用postgresql的內置統計信息來估計可能匹配的行數。您可以通過對查詢進行EXPLAIN來獲得數字。至少增加相關表格的統計目標，以獲得更準確的數字。由於規劃人員不知道不同謂詞之間的相關性，並假定它們不相關，因此數字可能仍然會顯着偏離多個謂詞。因此，像WHERE sex='male' AND has_breasts=true這樣的事情會認爲25％會匹配，這可能是一個數量級。如果通過分析運行解釋，您可以檢查規劃人員預計需要經過多少行以獲取結果的第一頁，實際需要多少行，並相應地縮放估算。這可能有點類似於谷歌用來估計有多少網頁符合您的查詢。如果我沒記錯，Lucene應該支持類似的估計。

來源

2010-06-17 16:32:45

您可能要考慮使用遊標。

來源

2010-06-17 18:55:15

你可以CREATE TABLE AS並將所有結果放在一個新表中。儘管如果TEMP表格不是選項，您必須管理創建的表格。

來源

2010-06-17 19:04:09