你的查詢很好,但它需要一些幫助(索引)來獲得更快的結果。
我沒有手頭資源(或訪問SQL),但我會嘗試從內存中爲您提供幫助。
從概念上講,回答該查詢的唯一方法是計算共享相同word_id的所有記錄。這意味着查詢引擎需要快速查找這些記錄。沒有word_id上的索引,數據庫唯一能做的就是一次遍歷表中的一條記錄,並繼續運行找到的每個單獨的word_id的總計。這通常需要臨時表,並且在掃描整個表之前不會派發任何結果。不好。
隨着word_id上的索引,它仍然需要通過表,所以你會認爲它沒有什麼幫助。但是,SQL引擎現在可以計算每個word_id的計數,而不必等到表的結尾:它可以分派行和word_id的值的計數(如果它通過您的where
子句),或者放棄該行(如果它不);這將導致服務器上的內存負載較低,可能部分響應,並且臨時表不再需要。第二個方面是並行性;通過word_id上的索引,SQL可以將作業分成塊,並使用不同的處理器核並行運行查詢(取決於硬件功能和現有工作負載)。
這可能足以幫助您查詢;但你必須嘗試看看:
CREATE INDEX someindexname ON sentence_word (word_id)
(T-SQL語法;其中SQL產品使用的是沒有指定)。如果這還不夠
(或不利於在所有),還有其他兩種解決方案。
首先,SQL允許您使用索引視圖和其他機制預先計算COUNT(*)。我手邊沒有細節(我不經常這樣做)。如果您的數據不會經常更改,那麼這會給您更快的結果,但複雜性和存儲空間有限。
此外,您可能需要考慮將查詢的結果存儲在單獨的表中。只有數據不會改變,或者按照精確的時間表(例如,在早上2點的數據刷新期間),或者如果數據變化很小,並且幾個小時內您可以忍受非完美的結果(您將不得不安排定期數據刷新);這就是窮人數據倉庫的道德等價物。
確定什麼適合您的最好方法是運行查詢並查看帶有和不帶有一些候選索引的查詢計劃。
哪些DBMS您使用的? – 2009-05-04 05:56:04
這是與MySQL(並使用HeidiSQL作爲客戶端訪問它) – Jeff 2009-05-04 21:30:53
另一個惱人的澄清...(對不起):數據不斷變化。約10k插入行/天和〜5k刪除行。所以我認爲這使得存儲或緩存結果不可能 – Jeff 2009-05-04 21:47:38