如何优化全文搜索?

发布于 2024-11-18 17:57:07 字数 206 浏览 0 评论 0原文

我知道关于这个主题已经有很多问题,但我需要更具体的信息。所以这里是:

  1. 理想情况下,使用最少的资源(CPU、内存)执行全文搜索的最大字符长度应该是多少?
  2. 我什么时候应该决定使用 LIKE %$str% 和全文搜索?
  3. 实现 LIKE %$str% 和全文搜索这两个版本并动态使用最佳版本是否很重要?

I know there are a lot of question already on this subject, but I needed more specific information. So here goes:

  1. Ideally what should be the maximum length of characters upon which a full text search can be performed using minimal resources (CPU, memory)?
  2. When should I decide between using the LIKE %$str% and full-text search?
  3. Is it important to have both versions LIKE %$str% and full-text search implemented and use the optimal one dynamically?

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

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

发布评论

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

评论(1

几度春秋 2024-11-25 17:57:07
  1. 据我所知,这取决于字数,而不是字符数。越少,mysql 就越快。但不要让它妨碍你。
  2. 如果可以使用全文搜索,则切勿使用 LIKE。除了您偶尔手动运行一次的查询并且您不想减慢该表上的插入速度之外。
    您知道索引中选择速度与插入速度的权衡吗?
  3. 在不手动运行的查询中始终使用 FT(全文)搜索。 LIKE 很慢,并且当行数增加时变得非常慢。这是因为 mysql 引擎必须查看每一行来回答您的查询。 《金融时报》保留了一个索引,并且确切地知道该去哪里寻找。
  1. As far as I know it depends on the number of words, not characters. The fewer, the faster mysql will be. But don't let that get in your way.
  2. Never use LIKE if you can use a full-text search. Except maybe for queries that you would manually run once in a while and you don't want to slow down the INSERTs on that table.
    You know the speed of select vs speed of insert tradeoff in indexes, right?
  3. Always use FT (full-text) search in queries that you don't run manually. LIKE is slow and becomes really slower when the number of rows increases. This is because the mysql engine has to look into EVERY row to answer your query. And FT keeps an index and knows exactly where to look.
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文