2010-09-20 50 views
2

我在SQLite的一個表,基本上有以下幾點:SQLite在數百萬行後變慢,如何加速?

id : integer (primary key) 
name: text 
timestamp: text 
data1: integer 
data2: integer 
... 
data6: integer 

我需要通過名稱和時間戳進行過濾,所以我有(名稱,時間戳)指數成立。

在100,000,000行,SQLite在查詢時進行爬網。瞭解索引可以將時間複雜度從O(n)降低到O(log n),但它似乎仍然太慢。我不想將數據分割成多個表格。有什麼建議麼?

+1

你能舉一個例子查詢嗎?有可能你的查詢沒有使用你的索引。 – xscott 2010-09-20 03:30:06

+0

-1:如箭頭所示「這個問題不清楚」。使用「慢」和樣本查詢的定義,「將成爲」這個問題很有用「 – msw 2010-09-20 04:12:21

回答

4

您的時間戳應該是數字。由於比較字符串的方式,在文本列上過濾將顯着減慢查詢速度。

如果你不這樣做,把指標上任何列進行排序(ORDER BY)或過濾(WHEREHAVINGJOIN ON等)。

最後,您過濾數據的順序可能會有很大差異。按數字時間戳和名稱過濾通常會比按名稱過濾和數字時間戳過濾快得多。嘗試改變你的表達式的順序。例如,WHERE day = ?, month = ?, year = ?通常比WHERE year = ?, month = ?, day = ?快得多。

+0

SQLite有一個內置的DATETIME格式,它使用整數將數據實際存儲在可讀的文本表示之後...... – 2014-01-12 03:24:41

+0

但它不是數據類型(存儲類),因此在進行任何查找時仍依賴於基礎數據類型。原來的問題基本上是關於性能調優,在這種情況下,我仍然建議在時間戳上強制實施一個'NUMERIC'數據類型。我想知道最終如何解決這個問題。 – Andrew 2014-01-12 08:11:07

4

對於笑聲,我創建了一個sqlite3數據庫,其中包含使用文本日期戳的包含100'000'000行,6GB未標記數據庫文件的OP架構。

通過索引,數據庫文件的大小加倍。與一個漂亮的行人臺式機老式2008(2GB RAM,5K BogoMIPS)查詢

select * from big where date = "2010-09-20 04:54:45.586836"; 

在小於8秒掛鐘時間返回10K行。我希望這些數字可用於比較。

+2

嘗試使用數字時間戳而不是日期字符串,並查看它有多快。如果表格索引正確,您應該看到怪物差異。 SQLite很煩人,因爲它沒有日期或時間數據類型。 – Andrew 2010-09-26 04:46:04