替代MS SQL 2005全文目錄

Question

我似乎無法從FullText目錄中獲得可接受的性能。我們有必要儘快運行100k以上的查詢。一些查詢使用FREETEXT有些不。這裏的一個查詢

IF EXISTS的例子（從的user_data d選擇1其中d.userid=@userid和FREETEXT（*，@activities）SET @匹配= 1

這可以3-15秒之間採取。如果可能，我需要它快得多< 1s

我喜歡全文查詢的「靈活性」，因爲它可以跨多列進行搜索，而且語法非常直觀，我寧可不使用Like聲明，因爲我們希望能夠匹配「Writer」和「Writing」等詞。

我試過了一些建議listen d在這裏http://msdn.microsoft.com/en-us/library/ms142560(SQL.90).aspx

我們有足夠多的內存和CPU，因爲我們可以負擔得起，但不幸的是，我們無法將目錄放在他們自己的磁盤控制器上。

我很沮喪，並準備探索全文查詢的其他替代方案。還有什麼能讓那種「作家」/「寫作」類似的比賽？也許甚至使用CLR的東西？

Answer 1

查閱這些替代品，但我懷疑他們會提高性能，而無需他們隔離到獨立的硬件：

Which search technology to use with ASP.NET?

Lucene.Net and SQL Server

Answer 2

由於FREETEXT的性質，其性能低於使用CONTAINS時的性能，這僅僅是因爲它必須考慮所給關鍵字的不太精確的替代方案。當您指定Write btw時，CONTAINS可以找到寫入，我不確定您是否已經檢查過CONTAINS是否會執行該操作。

此外，請務必避免SQL中的IF語句，因爲它們通常會導致每次查詢執行都會執行計劃的完整重新編譯，這可能會導致您看到的糟糕的性能。我不確定IF語句是如何使用的，因爲它可能在更大的一塊SQL中。嘗試將EXISTS查詢與更大的sql片段合併，因爲您可以從EXISTS中的SELECT語句內設置@match參數，或者完全擺脫該變量並在更大的查詢中使用EXISTS子句作爲謂詞。

SQL是一種面向集合的語言並被解釋。因此，擺脫命令式編程結構並使用sql的本地set-operators通常會更快。

Answer 3

也許https://github.com/MahyTim/LuceneNetSqlDirectory可以幫助你，它允許存儲LuceneNET SQLServer中的索引。