|
|
5 回复 | 直到 9 年前
|
1
3
如果您的速度减慢特别是文本字段的搜索(正如我从您提到的LIKE中推测的那样),那么最好的解决方案是构建一个索引表(不要与DB table索引一起使用,DB table索引也是答案的一部分)。 构建一个索引表,将记录的唯一ID从主表映射到文本字段的一组单词(每行1个单词)。如果有必要的话,可以在索引表的第三列中添加源字段,如果需要“相关性”功能,可以考虑字数。 使用触发器(使用拆分)或应用程序填充索引表-后者可能更好,只需使用要插入/更新的实际数据和已拆分的单词列表调用存储的proc即可。 这将立即大大加快文本搜索,因为它不再执行“LIKE”操作,并且能够在索引表上使用索引(并非双关语),而不会干扰对SKU和主表上类似内容的索引。 完全索引 -不一定在同一个计算索引(SKU、大小调整等)中,任何作为范围字段(大小调整或日期)搜索的字段都是聚集索引的最佳候选字段(只要按该字段增加的大致顺序插入记录,或者您不太关心插入/更新速度)。 对于任何详细的模式,您都需要发布您的表结构、现有索引、缓慢的查询以及现在针对这些缓慢查询的查询计划。 另一项是确保尽可能少的字段是文本字段,尤其是那些“可解码”的字段——您的注释在文本字段集中提到“是否已装箱”。如果是这样,我假设值为“是”/“否”或其他一些非常有限的数据集。如果是这样,只需存储有效值的数字代码,并在应用程序中执行en/de编码,然后按数字代码进行搜索。这不是一个巨大的速度提高,但仍然是一个进步。 |
|
|
2
3
您可以尝试使用Verity(或Solr,如果是CF9)搜索来索引db记录。
我从未通过Verity为数据库编制过索引,但我为大量PDF、Word文档等集合编制过索引,我记得搜索速度非常快。我不知道这是否有助于你目前的处境,但可能值得进一步研究。 |
|
|
3
2
我已经使用SQL的全文索引完成了这项工作。这将需要非常多的应用程序更改,除了添加全文索引外,不需要对数据库模式进行任何更改。 首先,将全文索引添加到表中。在全文索引中包含搜索应针对的所有列。我还建议让索引自动更新;这应该不是问题,除非您的SQL Server已经被征收了很高的税。 其次,要进行实际搜索,需要将查询转换为使用全文搜索。第一步是将搜索字符串转换为全文搜索字符串。为此,我将搜索字符串拆分为单词(使用Split方法),然后构建一个格式如下的搜索字符串:
这将返回两列:
我已经用过很多次类似的方法,而且我很幸运。 |
|
|
4
1
如果你想要一个真正的插件解决方案,那么你应该选择谷歌本身。这听起来像是你在做某种电子商务或商业网站(考虑到术语“SKU”的使用),所以你可能有某种产品页面的目录。如果您有一致的标记,那么您可以配置一个google设备或服务来完全执行您想要的操作。它将发送一个机器人来索引您的页面并查找您的字段。没有SQl,很少编码,它将不依赖于您的数据库,甚至不依赖于coldfusion。它也将是相当快和熟悉的客户。 我能够在大约6小时内用coldfusion网站完成这项工作,完成了!唯一需要注意的是,google的索引仅限于bot可以看到的内容,因此如果您想根据用户角色、权限或组限制访问,那么它可能不是您的解决方案(尽管您可以为google配置权限服务进行检查) |
|
|
5
-1
因为SQL Server是数据所在的位置,所以搜索性能可能会成为一个问题。请确保您正在搜索的列上有索引,如果使用了like,则无法使用;如果使用了like,则请从TABLEX中选择*,其中姓氏为“%FR%” 但是如果你像这样做的话,它可以使用一个索引,从表x中选择*,其中姓氏像'FR%'。这里的关键是允许尽可能多的第一个字符不是通配符。 https://web.archive.org/web/1/http://blogs.techrepublic%2ecom%2ecom/datacenter/?p=173 |
推荐文章