搜索執行困境：全文與普通SQL

Question

我有一個需要搜索的MySQL/Rails應用程序。以下是關於這些數據的一些信息：

• 用戶只在自己的數據中搜索，因此搜索範圍被user_id縮小爲開頭。

• 每個用戶將有多達約五千個記錄（他們積累的時間）。

• 我寫出了一個典型的用戶記錄到一個文本文件。文件大小爲2.9 MB。

• 搜索必須包含兩列：title和body。 title是一個varchar（255）列。 body是列類型文本。

• 這將被輕微使用。如果我平均每秒進行幾次搜索，那將是令人驚訝的。

• 它運行一個500 MB的CentOS 5 VPS機器。

• 我不想要相關性排名或任何類型的模糊性。搜索應該是確切的字符串，並可靠地返回包含該字符串的所有記錄。簡單日期順序 - 從最新到最舊。

• 我正在使用InnoDB表類型。

我在尋找普通的SQL搜索（通過searchlogic gem）或全文搜索使用獅身人面像和思維獅身人面像寶石。

獅身人面像非常快，思維獅身人面像很酷，但它增加了複雜性，維護守護進程的cron作業以維護索引。

我可以通過純SQL查找小規模應用程序嗎？

Answer 1

我會從簡單的開始 - 簡單的SQL可能會運行良好，並且如果搜索功能證明是瓶頸，您可以隨後切換到全文搜索。

我正在開發和維護一個具有類似於您的屬性的搜索功能的應用程序，而普通的SQL搜索對我來說迄今爲止工作得非常好。當我在一兩年前首次實現搜索功能時，我遇到了類似的性能問題，但我還沒有看到任何性能問題。

Answer 2

我認爲普通的SQL搜索不是好的選擇。由於我們在MySQL中獲取文本類型列的時候，無論緩存設置如何，請求總是落在硬盤上。

您只能在非常小的應用程序中使用純SQL搜索。

我更喜歡獅身人面像。

Answer 3

已經使用MySQL全文搜索大約4年，現在只是移動到獅身人面像，我會說使用全文布爾（即精確）語法的常規MySQL搜索將罰款。它速度很快，它將完全按照您的要求進行。您在任何時間搜索的數據量都很小。

唯一的問題可能是訂購結果。當您開始按照（例如）日期排序時，MySQL的全文搜索速度可能會變慢，因爲這需要您搜索整個表格，而不是僅搜索它發現的第一個 nn結果。這最終是我搬到獅身人面像的原因。

獅身人面像也很棒，所以不要害怕嘗試它，但它聽起來像您的情況下可能不需要額外的功能。