这种在 MySQL 中进行快速子字符串搜索的策略是否足够快？

Question

我有一个包含数百万行的 USER 表。我正在实现一个搜索功能，允许某人通过输入用户名来查找用户。这个自动完成功能需要非常快。鉴于在 MySQL 中，列索引使用 LIKE {string}% 加速查询，以下方法的性能是否足以在 200 毫秒内返回？ （注意：这里的内存开销不是问题，用户名最多 30 个字符）。

创建一个 USERSEARCH 表，该表具有用户表的外键和 索引 ngram 用户名列：

    USERSEARCH
    
    user_id    username_ngram   
    -------------------------
    1          crazyguy23         
    1          razyguy23       
    1          azyguy23      
    1          zyguy23       
    ...       

查询将是：

    SELECT user_id FROM myapp.usersearch WHERE username_ngram LIKE {string}%
    LIMIT 10

我知道存在第三方解决方案，但出于其他原因我想暂时远离它们。这种方法在速度方面可行吗？如果数据库需要检查所有 O(30n) 行，其中 n 是用户数，我是否高估了索引的功能？

Answer 1

可能不会。 union distinct 将处理每个子查询以完成。

如果您只想要任意行，请将其表述为：

(SELECT user_id
 FROM myapp.usersearch
 WHERE username_1 LIKE {string}%
 LIMIT 10
) UNION DISTINCT
(SELECT user_id
 FROM myapp.usersearch
 WHERE username_2 LIKE {string}%
 LIMIT 10
)
LIMIT 10;

这至少可以为您节省大量使用常用前缀的时间——比如'S'。

也就是说，这只是返回 10 个user_ids 的任意列表，而可能还有更多。

我不知道速度是否足以满足您的应用程序。您必须通过测试一组适当的数据来做出判断。

Answer 2

假设固态硬盘，那应该是非常快的，是的。

以下是一些进一步的优化：

1. 我会在您的查询中添加DISTINCT，因为多次返回相同的 user_id 是没有意义的。尤其是在搜索非常常见的前缀时，例如单个字母。

2. 还可以考虑仅搜索至少 3 个输入字母。 Less 往往毫无意义（因为希望您的用户名至少有 3 个字符长）并且对您的数据库造成不必要的打击。

3. 如果您不再添加任何列（我希望您不添加，因为此表是为了快速搜索！），我们可以做得更好。交换列。制作主键（username_ngram，user_id）。这样，您就可以直接在主键上进行搜索。 （请注意结果的字母顺序的额外好处！嗯...匹配的后缀上的字母，也就是说，不是完整的用户名。）

4. 确保您在 user_id 上有一个索引，以便在您需要更改用户名时能够为用户替换所有内容。 （为此，只需删除该 user_id 的所有行并插入全新的行。）

5. 也许我们可以做得更好。由于这只是为了快速搜索，您可以使用READ_UNCOMMITTED 的隔离级别。如果我没记错的话，这可以避免放置任何读锁，并且应该更快。它可以读取未提交的数据，但那又如何……然后，您只需在另一个表中查询任何结果 user_ids，如果该用户仍在创建中，则可能找不到它们。你没有失去任何东西。 :)

Answer 3

我认为您需要使用 mysql 全文索引来提高性能。 您需要更改语法以使用全文索引。

创建全文索引：

CREATE FULLTEXT INDEX ix_usersearch_username_ngram ON usersearch(username_ngram);

mysql官方文档如何使用全文索引：https://dev.mysql.com/doc/refman/8.0/en/fulltext-search.html