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 '%...'本质上就是放弃索引。从查询逻辑源头约束，比后期调优更有效。
