SQL中LIKE模糊查询性能差的核心在于无法有效利用索引，尤其前置通配符（如'%abc'）导致全表扫描；优化需避免前导%、改用反向存储或后缀字段索引、优先前缀匹配（'abc%'）、引入全文检索或专用搜索引擎。

SQL中LIKE模糊查询性能差，核心问题在于**无法有效利用索引**，尤其是以通配符开头（如LIKE '%abc'）时，数据库只能全表扫描。优化关键在于：避免前置通配符、合理设计索引、改用更高效匹配方式。

避免以%开头的模糊查询

前导通配符（LIKE '%xxx'）会让B+树索引完全失效，必须走全表扫描。能改写就尽量改写：

• 如果业务允许，把查询方向倒过来——比如查“以xxx结尾”，可将字段反向存储（如存reverse(name)），再用LIKE 'xxx%'，配合普通B-tree索引即可加速
• 对邮箱、域名等有固定后缀的场景，提取后缀字段单独建索引（如domain列），直接等值查询比LIKE '%@qq.com'快得多
• 用户搜索场景中，优先支持“前缀搜索”（LIKE 'xxx%'），它能用上索引；若必须支持任意位置匹配，考虑引入全文检索

为LIKE 'xxx%'创建合适的索引

LIKE 'abc%'可以走索引，但需满足条件：

• 字段上建了B-tree索引（普通索引即可，无需特殊类型）
• 查询条件是**最左前缀匹配**，且没有函数包裹（如UPPER(col) LIKE 'ABC%'会失效）
• 字符集和排序规则要一致，例如utf8mb4_0900_as_cs区分大小写时，LIKE 'Abc%'不会命中abc开头的行，除非明确指定collation

用全文索引替代复杂LIKE

当模糊需求变成“包含任意词”“多关键词组合”“相关性排序”时，LIKE已不是合适工具：

• MySQL 5.6+ 支持FULLTEXT索引（仅InnoDB/MyISAM），配合MATCH ... AGAINST语法，支持自然语言模式或布尔模式，速度远超LIKE '%word%'
• PostgreSQL可用tsvector + tsquery实现高性能全文搜索，还支持中文分词（配合插件如zhparser）
• 高并发、复杂检索场景建议交由Elasticsearch或Meilisearch等专用引擎，它们专为文本模糊、拼写容错、同义词等优化

其他实用技巧

小改进也能明显缓解压力：

• 加LIMIT限制返回条数，避免查出几万行只用前10条
• 用EXPLAIN确认执行计划是否走了索引，特别注意type是否为range或ref，而非ALL
• 对长文本字段（如TEXT），避免在该字段上直接LIKE，可额外维护简短摘要字段用于前缀匹配
• 高频模糊查询结果可缓存（如Redis存keyword → id list），尤其适合低更新、高查询的场景

不复杂但容易忽略。真正卡顿的往往不是单条SQL，而是没意识到LIKE '%...'本质上就是放弃索引。从查询逻辑源头约束，比后期调优更有效。