SQL模糊查询是业务开发中高频使用的功能，比如搜索商品名称、用户昵称等场景都需要用到，但默认的LIKE查询如果通配符放在开头，会触发全表扫描，数据量较大时查询耗时极长，需要针对性的优化方案。
传统模糊查询的性能问题
我们常用的模糊查询语法是LIKE关键字配合通配符%使用，当通配符出现在查询条件的开头时，数据库无法利用普通索引快速定位数据，只能逐行扫描全表匹配条件，数据量达到十万级以上时，查询耗时可能从几毫秒增长到几秒甚至更久。
比如下面这个查询语句，就是典型的低效模糊查询：
-- 通配符在开头，无法使用name字段的普通索引 SELECT * FROM user WHERE name LIKE '%张三%';
方案一：后缀匹配改造
如果业务场景只需要匹配字段的后缀内容，也就是查询以某个字符串结尾的数据，可以将通配符放在查询条件的末尾，这样数据库可以利用字段的普通索引快速检索，大幅提升查询效率。
比如需要查询所有名字以“张三”结尾的用户，就可以写成如下语句：
-- 通配符在末尾，可正常使用name字段的普通索引 SELECT * FROM user WHERE name LIKE '张三%';
如果业务需要同时支持前缀和后缀匹配，还可以对字段内容做反转存储，比如原字段是name，额外加一个reverse_name字段存储REVERSE(name)的结果，并给reverse_name建索引。查询后缀匹配时，把查询条件也反转后走前缀匹配逻辑：
-- 原查询：找name以'三'结尾的用户
-- 反转后查询：找reverse_name以REVERSE('三')即'三'开头的数据，走索引
SELECT * FROM user WHERE reverse_name LIKE '三%';
这种方案的优点是改造成本低，不需要依赖数据库的特殊功能，缺点是无法支持中间匹配的模糊查询，适用场景有限。
方案二：使用全文索引
如果需要支持任意位置的模糊匹配，比如同时支持前缀、后缀、中间匹配，全文索引是更合适的方案。主流的关系型数据库比如MySQL、PostgreSQL都支持全文索引功能，它会对字段内容做分词处理，建立专门的索引结构，查询时直接匹配分词结果，效率远高于全表扫描。
MySQL中全文索引的使用示例
首先给需要模糊查询的字段创建全文索引：
-- 给user表的name字段创建全文索引 ALTER TABLE user ADD FULLTEXT INDEX idx_name_fulltext (name);
然后使用MATCH...AGAINST语法代替LIKE做查询：
-- 查询name中包含'张三'的所有用户，支持任意位置匹配
SELECT * FROM user WHERE MATCH(name) AGAINST('张三' IN BOOLEAN MODE);
全文索引的优势是支持任意位置的模糊匹配，查询效率稳定，适合大数据量的场景，缺点是分词规则可能不符合部分特殊业务需求，比如需要精确匹配短字符串的场景，可能需要额外调整分词配置。
两种方案的选择建议
可以根据实际业务需求选择优化方案：
- 如果只需要后缀匹配或者前缀匹配，优先选择后缀匹配改造方案，实现简单且兼容性好
- 如果需要支持任意位置的模糊匹配，且数据量较大，优先选择全文索引方案，长期维护成本更低
- 如果数据量很小，比如表数据不足一万条，传统LIKE查询的性能损耗可以接受，不需要额外优化
另外需要注意，全文索引的分词最小长度、停用词等配置可以根据业务需求调整，避免过短的关键词无法被匹配到的问题。