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 通常放弃使用索引，转为全表扫描：

• 以 % 或 _ 开头：如 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 完全不适用，必须引入专业搜索引擎