我想要了解如何爲我們正在構建的應用程序創建搜索。我想就如何通過大量數據進行「搜索」提出建議。使用SQL Server（和/或coldfusion）創建高效的搜索功能
舉例來說，這種特殊的搜索將是一個750K記錄表的最小，產品的SKU，尺寸，材料類型，創建日期等;
有人知道Coldfusion的'插件'解決方案嗎？我設想一個像單一條目搜索一樣的谷歌，客戶可以輸入零件號碼或尺寸等，並獲得任何或所有相關結果的點擊。
目前，如果我運行一個「喜歡」比較查詢時，它似乎採取年齡（好幾秒，但仍然），它是太長。有時會讓用戶坐在那裏，等待10秒鐘以查詢&頁面加載。
或者是否有任何SQL公式來幫助完成此操作？我想使用一種經過驗證的方法來搜索數據，而不僅僅是一個簡單的SQL類似或=比較操作。
所以這是一個多方法的問題，我應該在SQL級別上進行攻擊（因爲它最終看起來是這樣），還是有一個ColdFusion的插件/模塊，我可以抓住它，這會讓我快速，高級搜索能力。
你可以嘗試用Verity（或Solr，如果是CF9）搜索索引你的db記錄。
我不確定它會更快，甚至嘗試它是否值得，將取決於您更新需要搜索的記錄的頻率。如果您很少更新它們，則只要您更新它們就可以進行Verity索引更新。如果您不斷更新記錄，這將成爲網絡服務器上的一個阻力，並且肯定會降低搜索速度方面的任何可能的收益。
我從來沒有通過Verity對數據庫建立索引，但是我已經對大量的PDF，Word Docs等進行了索引，我記得搜索速度非常快。我不知道這是否會有助於你目前的狀況，但可能值得進一步研究。
如果你的放緩特別是文本字段的搜索（正如我從你提到的LIKE中推測出的那樣），最好的解決方案是構建一個索引表（不要與數據庫表索引混淆，這也是答案的一部分） 。
建立索引表，從主表的記錄的唯一ID映射到文本字段中的一組字（每行1個字）。如果它很重要，請將索引表中的原始字段添加爲第三列，如果您想要「相關」功能，則可能需要考慮字數。
用觸發器（使用分割）或從您的應用程序填充索引表 - 後者可能更好，只需調用一個存儲過程，同時插入/更新實際數據和已經分割的單詞列表。
這將立即大大加快文本搜索，因爲它不會再執行「LIKE」，並且能夠在索引表上使用索引（無雙關語），而不會干擾主表上的SKU等上的索引。
此外，確保所有相關的字段索引完全 - 不一定在同一複方指數（SKU，大小等），而被搜索的範圍字段的任何字段（大小或日期）是聚簇索引的一個很好的候選者（只要記錄按照字段的增加順序插入，或者你不關心插入/更新速度）。
對於任何模式的詳情，您將需要發佈你的表結構，現有的索引，速度很慢的查詢和查詢計劃，你現在對那些慢查詢。
另一個項目是enure儘可能少的字段是文本成爲可能，特別是那些有「解碼」 - 提到您的評論「是盒裝」中設置的文本字段。如果是這樣，我假設這些值是「是」/「否」或其他一些非常有限的數據集。如果是這樣，只需存儲有效值的數字代碼並在您的應用中進行en/de-coding，然後通過數字代碼進行搜索。速度不是很大的提高，但仍然有所提高。
是的，可搜索的數據是全部文本，它主要是一大組產品相關數據，正如我提到的大小，材質，產品sku，部件號，盒裝等等;目前，我在零件號碼錶上有一個索引，因爲我們的大多數客戶都是通過零件號進行搜索，但是當通過其他標準進行搜索時，返回的速度很慢，因爲我主要是通過LIKE操作員和通配符來攻擊匹配部分。 我有一個夜間重新索引的數據庫（因爲數據不斷增加，每天幾千條記錄）。所以我們編制了索引表。 – Jakub 2009-11-04 14:37:05
我更新了答案，以澄清「索引」意味着構建一個名爲「索引」的表，而不是（或者除此之外）構建數據庫表索引，以防原始文字中100％不清楚 – DVK 2009-11-04 14:45:00
Alsi增加了一個點re ：使用數字代碼實質上是「枚舉」的字段 - 例如有非常小的一組有效文本值。 – DVK 2009-11-04 14:47:46
因爲SQL Server是您的數據所在，那麼您的搜索性能將成爲一個可能的問題。確保你在搜索的列上有索引，如果使用像你不能使用和索引，如果你這樣做SELECT * FROM TABLEX WHERE last_name LIKE'％FR％'
但它可以使用索引如果你這樣做SELECT * FROM TABLEX WHERE last_name LIKE'FR％'。這裏的關鍵是允許儘可能多的第一個字符不是通配符。
這裏是一個網站的鏈接，提供一些一般性提示。 https://web.archive.org/web/1/http://blogs.techrepublic%2ecom%2ecom/datacenter/?p=173
嗯......能夠使用具有起始字母匹配的LIKE的索引的好點，但LIKE仍然比精確的相等搜索要慢（並且OP的描述似乎不像搜索會傾向於開始 - 至少對我來說） – DVK 2009-11-04 14:31:29
對不起，你的例子並不適用於這個問題的範圍。你已經展示了一個基本的'比較'，我提到我想避免使用，因爲它是昂貴的。 – Jakub 2009-11-04 14:32:39
是的，但我的觀點是，如果你以正確的方式使用LIKE，它可能並不昂貴。你將需要測試來驗證。對我而言，這是測試的最小變化量，並可能解決您的「緩慢問題」。 – Kuberchaun 2009-11-04 14:45:27
如果你想要一個真正的插件解決方案，那麼你應該只與谷歌自己。這聽起來像是你在做某種電子商務或商業網站（因爲使用了「SKU」），所以你可能有一個產品頁面的目錄。如果您擁有一致的標記，那麼您可以將Google設備或服務配置爲按照自己的意願進行操作。它會發送一個bot來索引你的頁面並找到你的字段。沒有SQl，很少的編碼，它不會依賴於你的數據庫，甚至不依賴於Coldfusion。這對客戶來說也是相當快速和熟悉的。
我可以在6個小時內用coldfusion網站做到這一點，完成了！唯一需要注意的是，Google的索引僅限於機器人可以看到的內容，因此如果您有一種情況需要根據用戶角色或權限或組來限制訪問權限，那麼它可能不是解決方案你（雖然你可以配置谷歌的權限服務來檢查）
你已經擊中了頭，它是一個電子商務網站，但該網站將基於角色的權限結構，所以這確實提出了'如何'蜘蛛這些結果的關注。因爲我們可能會讓某些用戶訪問查看股票，而其他用戶則不會看到。我不太熟悉谷歌整合如何工作（購買1U谷歌蜘蛛服務器等）。我一直認爲它主要用於文件回收，靜態內容，因爲大部分數據都存儲在數據庫中。 – Jakub 2009-11-04 15:52:19
我已經完成了這個使用SQL的全文索引。這將需要非常多的應用程序更改，除了添加全文索引外，不需要更改數據庫模式。
首先，將全文索引添加到表中。在全文索引中包含搜索應執行的所有列。我也建議讓索引自動更新;這不應該是一個問題，除非你的SQL Server已經被高度徵稅。
其次，要進行實際的搜索，您需要將您的查詢轉換爲使用全文搜索。第一步是將搜索字符串轉換爲全文搜索字符串。
：我通過分割搜索字符串的話（使用分割法），然後建立格式化爲搜索字符串做到這一點「字1 *」和「字2 *」和「WORD3 *」
雙引號是至關重要的;他們告訴全文索引詞的開始和結束。
接下來，實際執行的全文檢索，在查詢使用CONTAINSTABLE命令：
SELECT *
from containstable(Bugs, *, '"Word1*" AND "Word2*" AND "Word3*"')
這將返回兩列：
我已經使用了類似於這個很多次的方法，並且我有很好的運氣。
問題是我們相當頻繁地更新它們，不僅僅是產品數據，而是更多購買數據（訂單歷史記錄）或帳戶信息，這些數據會從我們的ERP平臺同步到電子商務應用程序） – Jakub 2009-11-04 16:29:23
這不是問題 - 啓動更新過程重新索引數據;或按照計劃進行，如每晚過夜。如果你有ColdFusion，你應該使用Verity，Lucene或者Solr。他們在做什麼都很不可思議，並且包括在內，所以要充分利用它們！ – 2009-11-05 12:23:22