SQLite的查詢延遲

我有一個非常簡單的查詢：SQLite的查詢延遲

SELECT count(id), min(id), max(id), sum(size), sum(frames), sum(catalog_size + file_size) 
FROM table1

table1擁有約3000至4000分的記錄。

我的問題是，這個查詢需要大約20秒才能運行。由於它被稱爲不止一次，延遲對客戶來說非常明顯。

這個查詢花費20秒是否正常？有什麼方法可以改善運行時間嗎？如果我從SQLite Manager運行相同的查詢，則需要幾毫秒才能執行。只有當我們的軟件調用查詢時纔會出現延遲。 EXPLAIN和EXPLAIN QUERY PLAN沒有什麼幫助。我們使用SQLite 3.7.3版本和Windows XPe。

任何想法如何解決這個問題或提高查詢的性能？

來源

2012-10-19 ViP

您是否有'id'索引？ – 2012-10-19 13:52:59

id是主鍵。 – ViP

索引在這裏並不重要。它仍然需要閱讀表格中的每條記錄。如果唯一的聚合是'count（id），min（id），max（id）'，那麼規劃師可以使用該索引。之後的sum（）意味着整個表必須被執行。 –

所有sum都要求必須讀取表中的每一條記錄。

如果表中包含的列多於上面顯示的列，那麼從磁盤讀取的數據包含有用和無用的值（特別是如果您有大塊）。在這種情況下，您可以嘗試通過創建一個covering index而不是此查詢所需的列來減少需要爲此查詢讀取的數據。
在3.7.15之前的SQLite版本中，您需要爲第一個索引字段添加ORDER BY以強制SQLite使用該索引，但這不適用於所有查詢。（對於您的查詢，請嘗試更新至this beta，或等待3.7.15。）

來源

2012-10-19 15:31:13

你是正確的，我確實有更多的列比這個查詢需要包括blob。您的建議聽起來像是一個非常好的主意，不幸的是，添加覆蓋索引似乎不會影響查詢運行時間。 – ViP

使用['EXPLING QUERY PLAN']（http://www.sqlite.org/lang_explain.html）檢查索引是否被使用。在3.7.15之前，如果不需要排序或分組，SQLite查詢規劃器不會使用它。 –

感謝您提出這些想法。根據「EXPLAIN QUERY PLAN」，索引沒有被使用，我無法強制SQLite使用它。我還沒有嘗試3.7.15升級。 – ViP

SQLite的查詢延遲

回答

相關問題