SQLite在大型表上的性能

Question

編輯：我的錯在這裏是非常基本的：我沒有使用PRIMARY KEY索引。爲了使這個線程更有用，我添加了性能數據，用於搜索我的表，並且不用索引進行性能比較。

我在一個運行在windows和linux下的應用程序中使用python中的sqlite3。我的數據庫文件當前在700 MB的範圍內。

我認識到一個關於我最大表中條目數量的特殊性能問題。它由10個列組成，整數和浮點數以及一個varchar。

該表有1.6 Mio行。對於那個尺寸，每個SELECT或UPDATE命令需要327ms。這對於我的應用來說太長了，因爲它現在主要在sqlite上等待。

我認識到，隨着表格大小的下降，性能會急劇增加。我發現：

• 1.6M條目327毫秒的w/o索引=> 29.7毫秒索引
• 670K條目149毫秒的w/o索引=> 28.8毫秒索引
• 280K條目71毫秒瓦特/ O索引=> 28.5毫秒索引
• 147K條目44毫秒的w/o索引=> 28.0毫秒索引
• 19K條目25毫秒的w/o索引=> 25.0毫秒索引

CONCLUSI ON：使用索引搜索時間幾乎保持不變，而搜索次數幾乎線性地隨着表大小而增加。只有非常小的表格才能忽略不同。

Answer 1

當查詢時間與表大小成線性關係時，您的查詢可能會執行全表掃描，這意味着它們必須讀取表中的所有行。這通常意味着它們不是using indexes。

我們不能告訴你什麼你應該索引而不看你的模式和查詢。您可以通過將EXPLAIN QUERY PLAN放在它的前面來查看您的查詢在做什麼，如EXPLAIN QUERY PLAN SELECT * FROM foo。如果您看到「掃描表」是全表掃描。如果您看到使用索引的「USING INDEX」。

Answer 2

確保SELECT和UPDATE的WHERE（和JOIN，如果使用）子句中的每個列都出現在索引中，或者是表的主鍵的一部分。

還要注意，由索引引起的性能改進與查詢結果的常量大小有關。如果查詢結果的數量與表大小呈線性增長，則索引的效果會受到限制，因爲結果數據量轉移回應用程序不會有意義地減少。在這種情況下，您可能需要進行更深入的性能分析。