高效应对千万级mysql数据模糊搜索：秒级查询的内存优化方案
面对千万级数据的MySQL数据库，select * from table where title like %关键词% limit 100 这样的模糊搜索往往耗时10秒甚至更久，这是因为模糊查询无法利用索引，只能进行全表扫描。本文针对内存受限（例如仅有512M Java堆内存）的情况，探讨如何在不增加内存占用情况下，实现秒级模糊搜索。
文章首先排除了几种常见方案：Elasticsearch（维护成本高、资源消耗大）、MySQL分词索引（中文支持不佳，搜索精度低）、手动维护索引表（代码复杂，影响精度）、分库分表（不在考虑范围内）。 作者也尝试过将数据加载到内存进行搜索，在300万数据量下实现了500ms的查询速度，但无法扩展到千万级数据。
最终，本文提出了一种基于自定义索引表的解决方案，其核心在于：创建一张索引表，存储每个记录标题的分词及其相邻词，以及对应的记录主键ID。
索引表结构示例：
| 当前词 | 下一词 | 原记录主键ID |
|---|---|---|
| mysql | 一 | 1 |
| 一 | 千 | 1 |
| 千 | 万 | 1 |
| ... | ... | ... |
| 模 | 糊 | 1 |
| 糊 | 搜 | 1 |
| 搜 | 索 | 1 |
| 索 | NULL | 1 |
搜索“模糊搜索”时，通过索引表依次查找“模-糊”、“糊-搜”、“搜-索”、“索-NULL”对应的记录主键ID，最终得到结果。这有效减少了需要扫描的数据量。
示例SQL语句：
SELECT 原记录主键ID FROM (SELECT 原记录主键ID FROM 索引表 WHERE 当前词 = '模' AND 下一词 = '糊') a JOIN (SELECT 原记录主键ID FROM 索引表 WHERE 当前词 = '糊' AND 下一词 = '搜') b USING(原记录主键ID) JOIN (SELECT 原记录主键ID FROM 索引表 WHERE 当前词 = '搜' AND 下一词 = '索') c USING(原记录主键ID) JOIN (SELECT 原记录主键ID FROM 索引表 WHERE 当前词 = '索' AND 下一词 IS NULL) d USING(原记录主键ID)
此方案虽然需要预先构建索引表，增加了一定的存储空间和维护成本，但显著提升了搜索效率，并且适用于内存受限的环境。 实际应用中，可以根据情况调整分词策略和SQL语句以优化性能。 文章并未深入探讨类似Everything软件的高效搜索机制。
