【问题标题】:Big-O of MySQL Fuzzy SearchMySQL 模糊搜索的 Big-O
【发布时间】:2016-07-01 08:58:16
【问题描述】:

什么是 MySQL 模糊搜索的 Big-O?它是否因索引类型而异,如果有,什么表现最好?

例如SELECT * FROM foo WHERE field1 LIKE '%ello Wo%';

我不确定底层数据类型,它拥有什么样的魔力。像 trie (https://en.wikipedia.org/wiki/Trie) 这样的东西对于最后模糊的搜索会很好,例如LIKE 'Hello Wo%'.

我猜 Big-O 是O(n),但希望确认一下。甚至模糊搜索之间也可能存在差异,例如%ello Wo% vs. Hello W% vs. %lo World vs. %ell%o%W%or%

是否有不同的索引方法可以提供更好的性能?如果是的话,对于特殊情况,你能分享一下吗?

【问题讨论】:

标签: mysql database indexing big-o fuzzy-search


【解决方案1】:

带有前导通配符

MySQL 会

  1. 扫描表中的所有行(不是索引)。这称为“表扫描”。 (这是假设没有进行其他过滤。)
  2. 对于每一行,在有问题的列中扫描LIKE
  3. 传递未过滤掉的行。

大部分时间都花在第 1 步,这是 O(N),其中 N 是行数。第 2 步和第 3 步花费的时间要少得多。

没有前导通配符

  1. 使用该列上的索引,如果你有一个,以限制要搜索的行数。如果您在列上有一个索引并且说WHERE col LIKE 'Hello W%',它将找到索引中以Hello W 开头的所有行。它们将在索引中连续,使这一步更快。
  2. 对于其中的每一个,进入该行的数据并执行其他任何需要的操作。

有许多变量(缓存、行数、行的随机性等)会导致 #1 的成本高于或低于 #2。但这可能比前导通配符情况快得多 - O(n),其中n 是以“Hello W”开头的行数。

【讨论】:

  • 感谢您的回答,瑞克!您知道在哪里可以找到有关索引复杂性的官方信息吗?不是因为我完全怀疑答案,而是为了了解更多信息并查找不同的案例。
  • @Luc - MySQL 的“官方”文档在线。问题是将其应用到现实生活中。为此,我写了一个cookbook on how to create an index, given a Select
猜你喜欢
  • 1970-01-01
  • 2017-01-01
  • 1970-01-01
  • 2013-02-18
  • 1970-01-01
  • 2020-03-15
  • 2014-08-20
  • 2011-10-28
  • 2016-06-12
相关资源
最近更新 更多