MySQL的LIKE查询能否走索引取决于通配符位置：仅前缀匹配（如'abc%'）和带确定前缀的单字符匹配（如'A_1'）可命中索引；以'%'或'_'开头、中间模糊或OR中混用无效LIKE则索引失效。
MySQL 的 LIKE 查询能不能走索引，关键看通配符的位置——只有前缀匹配（LIKE 'abc%'）才可能命中索引；后缀或中间模糊（LIKE '%abc' 或 LIKE '%abc%'）基本都会导致全表扫描。
哪些 LIKE 写法能用上索引
满足“最左前缀匹配”原则时，索引才生效：
-
前缀匹配有效：如
name LIKE '张%'、code LIKE 'A01%'，B+ 树可快速定位起始位置，范围扫描后续数据 -
多列索引中，LIKE 字段必须在最左连续位置：例如联合索引
(status, name)，WHERE status = 'active' AND name LIKE 'John%'可用索引；但WHERE name LIKE 'John%'单独查则无法使用 -
单字符匹配
_也支持索引：如code LIKE 'A_1'（第二位任意单字符），前提是不以_开头且前面有确定前缀
哪些写法会让索引完全失效
以下情况 MySQL 通常放弃使用索引，转为全表扫描：
word报告自动生成神器
下载
Word报告自动生成神器。自动生成专业Word文档报告，支持模板填充、目录生成、表格/图表插入、页眉页脚、多级标题、样式主题、批量邮件合并。当用户需要生成Word报告、创建合同文档、批量生成通知/证书、填充Word模板、制作商业计划书时触发。
-
以
%或_开头：如name LIKE '%三'、title LIKE '_a%'，无法确定索引查找起点 -
中间模糊：如
content LIKE '%error%'，必须逐行扫描判断 -
OR 条件中混入无效 LIKE：例如
WHERE id = 10 OR name LIKE '%test%'，整个条件大概率退化为全表扫描
提升 LIKE 查询性能的实用技巧
不改业务逻辑的前提下，有几种高效替代或优化路径：
-
优先改写为前缀查询：比如搜索“手机”，若业务允许，引导用户输入开头关键词，用
LIKE '手机%'替代LIKE '%手机%' -
用覆盖索引减少回表：确保
SELECT字段和WHERE中的LIKE字段都在同一索引里，例如建索引INDEX idx_name_email (name, email)，再查SELECT name, email FROM user WHERE name LIKE '李%' -
对长文本字段加前缀索引：如
ALTER TABLE article ADD INDEX idx_title_prefix (title(20))，配合title LIKE 'MySQL%'使用，避免全文本索引开销 -
中文场景慎用 FULLTEXT：默认只支持英文分词；如需中文支持，需调低
ft_min_word_len=1并配合自定义分词（如把“数据库”拆成“数”“数据”“数据库”），再用MATCH() AGAINST()
什么时候该换方案，而不是硬扛 LIKE
当模糊需求复杂、数据量大、响应要求高时，LIKE 就不是最优解：
- 高频全文检索（如日志、文章内容）→ 用 Elasticsearch 或 Solr
- 结构化+关键词混合搜索（如商品标题+属性）→ 建立 倒排索引表 或使用
REGEXP配合生成列 - 需要高亮、相关性排序、同义词扩展 → 原生 LIKE 完全不适用，必须引入专业搜索引擎
