我想要了解如何为我们正在构建的应用程序创建搜索。我想就如何通过大量数据进行“搜索”提出建议。使用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