MySQL的like查询是处理模糊匹配需求的常用方式，在用户搜索、内容筛选等场景中应用广泛，但错误的使用方式很容易引发全表扫描，导致查询性能大幅下降。
like查询的性能影响因素
like查询的性能核心取决于是否能够有效利用索引，而通配符的位置直接决定了索引的可用性：
- 当通配符
%放在匹配字符串的末尾时，属于前缀匹配，能够正常使用B树索引 - 当通配符
%放在匹配字符串的开头时，属于前置通配符匹配，会导致索引失效，触发全表扫描 - 匹配字符串的长度越长，扫描的数据范围越小，查询效率相对越高
基础优化技巧
1. 避免前置通配符匹配
如果业务允许，尽量将匹配规则调整为前缀匹配，让查询能够走索引。例如需要查询用户名中包含test的用户，如果业务支持查询以test开头的用户名，就可以调整为下面的查询方式：
-- 前置通配符匹配，索引失效 SELECT * FROM user WHERE username LIKE '%test%'; -- 前缀匹配，可使用索引 SELECT * FROM user WHERE username LIKE 'test%';
2. 合理创建索引
针对常用的like查询字段创建合适的索引，注意索引的长度不需要覆盖整个字段，可根据实际业务场景截取前缀长度，减少索引占用的存储空间。例如用户名字段平均长度为20，实际匹配只需要前10位就能区分大部分数据，就可以创建前缀索引：
-- 创建username字段的前缀索引，长度为10 CREATE INDEX idx_username_prefix ON user(username(10));
进阶优化方案
1. 使用覆盖索引减少回表
如果查询的字段都包含在索引中，就不需要回表查询聚簇索引的数据，能够进一步提升查询效率。例如查询只需要返回用户的id和用户名，就可以创建包含这两个字段的联合索引：
-- 创建联合索引，包含id和username CREATE INDEX idx_id_username ON user(id, username); -- 查询只需要返回索引包含的字段，不需要回表 SELECT id, username FROM user WHERE username LIKE 'test%';
2. 借助全文索引处理复杂模糊匹配
如果业务必须使用前后都带通配符的模糊匹配，且数据量较大，可以考虑使用MySQL的全文索引替代like查询。全文索引适合处理大文本字段的模糊匹配场景，查询效率远高于全表扫描的like查询：
-- 给content字段创建全文索引
CREATE FULLTEXT INDEX idx_content_full ON article(content);
-- 使用全文索引查询包含test的内容
SELECT * FROM article WHERE MATCH(content) AGAINST('test');
3. 数据量分级处理
如果表的数据量非常大，且模糊匹配的需求比较固定，可以将数据按照匹配规则提前分级存储，例如将用户名按照首字母拆分到不同的表中，查询时直接定位到对应的表进行查询，避免大表的全表扫描。
不同匹配场景性能对比
下面通过一组简单的测试数据对比不同like匹配方式的查询耗时，测试表user有100万条数据，username字段创建了普通索引：
| 查询方式 | 是否使用索引 | 平均查询耗时（毫秒） |
|---|---|---|
| LIKE 'test%' | 是 | 12 |
| LIKE '%test' | 否 | 820 |
| LIKE '%test%' | 否 | 950 |
从测试结果可以明显看出，前缀匹配的查询效率远高于前置通配符匹配，在数据量较大的场景下差距会更加明显。
注意事项
- 不要盲目给所有字段创建索引，索引会增加写操作的开销，需要根据实际查询频率合理设计
- 全文索引对中文的支持需要MySQL版本在5.7以上，且需要配置合适的分词规则
- 如果模糊匹配的需求非常复杂，且数据量极大，也可以考虑引入Elasticsearch等专门的搜索引擎处理，比MySQL的原生查询效率更高