如何获得闪电般的快速搜索?
我刚刚访问了这个网站: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 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
您必须在包含搜索词的列上添加索引,即使是 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.
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.
您将需要对表进行表扫描,因此我建议:
如果行数很小,则对 7000 行表进行表扫描应该非常高效;我从你的问题域了解到情况会是这样。
但正如其他人指出的那样,当客户端不需要时,不要将 7000 行发送到客户端。
传统索引可以将 LIKE 'someprefix%' 优化为范围扫描,因此拥有一个索引可能会有所帮助。如果你想在条目的任何部分搜索字符串,这将是一个表扫描(在这么小的表上这应该不会慢!)
You will need to table-scan the table, so I suggest:
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!)