如何获得闪电般的快速搜索?

发布于 2024-11-09 06:56:08 字数 480 浏览 0 评论 0原文

我刚刚访问了这个网站:http://www.hittaplagget.se。如果您输入以下搜索词 moo,自动提示会立即弹出。

但是,如果您访问我的网站 http://storelocator.no,并使用相同的搜索短语(在“搜索品牌”字段),自动建议需要更长的时间才能提出任何建议。

我知道我们只能猜测他们正在使用什么类型的技术,但希望这里有人能比我更好地进行教育性猜测。

在我的解决方案中,我只执行 SELECT moo% FROM table 并返回结果。 我还没有为我的表建立索引,因为它只有 7000 行。但我正在考虑使用 Lucene 为我的表建立索引。

谁能建议我需要做什么才能获得同样快速的自动建议?

I just came over this site: http://www.hittaplagget.se. If you enter the following search word moo, the autosuggest pops up immediately.

But if you go to my site, http://storelocator.no, and use the same search phrase (in "Search for brand" field), it takes a lot longer for autosuggest to suggest anything.

I know that we can only guess on what type of technology they are using, but hopefully someone here can do an educational guess better than I can.

In my solution I only do a SELECT moo% FROM table and return the results.
I have yet not indexed my table as there are only 7000 rows in it. But I'm thinking of indexing my tables using Lucene.

Can anyone suggest what I need to do in order to get equally fast autosuggest?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

俯瞰星空 2024-11-16 06:56:08

您必须在包含搜索词的列上添加索引,即使是 7000 - 否则,数据库每次都会搜索整个列表。请参阅http://dev.mysql.com/doc/refman/ 5.0/en/create-index.html

You must add an index on the column holding your search terms, even at 7000 - otherwise, the database searching through the whole list every time. See http://dev.mysql.com/doc/refman/5.0/en/create-index.html.

风为裳 2024-11-16 06:56:08

Lucene 是一个全文搜索索引,可能是也可能不是您正在寻找的内容。 Lucene 会在整个索引列(例如 Mootastic 和 Fantasticmoo)中找到任何出现的“moo”,并且不一定会加快搜索速度,尽管它比 where x like '%moo%' 类型的搜索更快。

正如其他人已经指出的那样,如果您执行“开头为”类型的搜索,则您想要的是常规索引(甚至可能是唯一的?)。

Lucene is a full text search index and may or may not be what you're looking for. Lucene would find any occurrence of "moo" in the entire indexed column (e.g. Mootastic and Fantasticmoo) and does not necessarily speed up your search although it's faster than a where x like '%moo%' type of search.

As others have already pointed out a regular index (probably even unique?) is what you want if you're performing "starts with" type of searches.

唱一曲作罢 2024-11-16 06:56:08

您将需要对表进行表扫描,因此我建议:

  • 不要在表中放入不需要的任何行 - 例如,“非活动”记录 - 将它们保留在不同的表中
  • 不要将任何列放入您不需要的表
  • 您可以通过使用特殊的“搜索表”来实现此目的,其中仅包含您感兴趣的行/列,并从“主表”中更新它。

如果行数很小,则对 7000 行表进行表扫描应该非常高效;我从你的问题域了解到情况会是这样。

但正如其他人指出的那样,当客户端不需要时,不要将 7000 行发送到客户端。

传统索引可以将 LIKE 'someprefix%' 优化为范围扫描,因此拥有一个索引可能会有所帮助。如果你想在条目的任何部分搜索字符串,这将是一个表扫描(在这么小的表上这应该不会慢!)

You will need to table-scan the table, so I suggest:

  • Don't put any rows in the table you don't need - for example, "inactive" records - keep them in a different table
  • Don't put any columns in the table you don't need
  • You can achieve this by having a special "Search table" which just contains the rows/columns you're interested in, and updating it from the "Master table".

Table-scanning a 7000 row table should be extremely efficient if the rows are small; I understand from your problem domain that this will be the case.

But as others have pointed out - don't send the 7000 rows to the client-side when it doesn't need it.

A conventional index can optimise a LIKE 'someprefix%' into a range-scan, so it is probably helpful having one. If you want to search for the string in any part of the entry, it is going to be a table-scan (which should not be slow on such a tiny table!)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文