MySQL 的 LIKE '%abc' 或 LIKE '%abc%' 永远不会走 B+ 树索引，因 B+ 树按字典序排序，无法锚定后缀匹配起点；需用 REVERSE()+索引、FULLTEXT 或专用搜索引擎替代。
MySQL 的 LIKE '%abc' 或 LIKE '%abc%' 永远不会走 B+ 树索引——这不是配置问题，也不是 SQL 写得不够“规范”，是 InnoDB 索引结构决定的硬限制。
为什么 LIKE '%abc' 一定不走索引
B+ 树索引按字段值字典序排序，查找必须从一个确定前缀开始向右遍历。LIKE 'abc%' 能定位到第一个 ≥ 'abc' 的记录，然后范围扫描；而 LIKE '%abc' 要匹配“结尾为 abc”的字符串，索引里没有反向顺序，无法锚定起点。执行计划中 type 必为 ALL，key 必为 NULL。
常见错误现象：
- 明明给
name建了索引，EXPLAIN却显示possible_keys为空 - 加
FORCE INDEX也无效，优化器直接忽略 - 复合索引
(status, name)对name LIKE '%abc'完全无用——该字段在索引中不可用
短字段后缀匹配：用 REVERSE() + 普通索引
适用于用户名、编码、文件名等长度可控（≤ 50 字符）、高频后缀查询的场景。核心是把后缀匹配转成前缀匹配。
实操步骤：
- 新增冗余列：
ALTER TABLE user ADD COLUMN name_reversed VARCHAR(50) STORED AS (REVERSE(name)) - 对该列建普通索引：
CREATE INDEX idx_name_reversed ON user(name_reversed) - 查询时改写：
WHERE name_reversed LIKE REVERSE('abc') + '%'（注意：MySQL 中用CONCAT(REVERSE('abc'), '%')）
性能影响：写入时多一次函数计算，但索引体积小、范围扫描快；100 万行表上，典型查询可从 2s 降到 20ms。
中长文本含子串匹配：改用 FULLTEXT 索引
适合标题、简介、描述类字段（≥ 50 字符），且业务能接受分词语义（如搜“苹果”可能命中“苹果手机”“红富士苹果”）。
关键注意事项：
-
ft_min_word_len默认为 4，搜“go”“ai”会查不到，需修改配置并重建索引 - 中文需配合
ngram插件（MySQL 5.7.6+），否则默认按空格/标点切分，对无空格中文无效 - 字段不能有函数包裹：
MATCH(UPPER(name)) AGAINST(...)会导致索引失效 - 字符集不一致（如字段是
utf8mb4_0900_as_cs，查询字面量未声明 collation）会触发隐式转换，索引失效
示例写法：SELECT * FROM article WHERE MATCH(title) AGAINST('数据库优化' IN NATURAL LANGUAGE MODE)
高并发/复杂模糊需求：别硬扛，换专用搜索引擎
当出现以下任一情况，就该放弃在 MySQL 里做模糊匹配：
- 需要高亮、拼写纠错、同义词扩展
- QPS > 50，且
LIKE '%keyword%'查询占比 > 20% - 字段内容动态更新频繁，
FULLTEXT同步延迟不可接受
推荐路径：
- 轻量级：用
Meilisearch（Rust 编写，开箱即用，支持中文 n-gram） - 成熟生态：同步数据到
Elasticsearch，用match_phrase或wildcard查询 - MySQL 仅作源库，所有模糊查询路由到搜索服务
最容易被忽略的一点：即使加了 FULLTEXT 索引，只要查询词长度 ft_min_word_len，或字段用了函数、collation 不一致，索引就形同虚设——它不会报错，但性能和全表扫描没区别。
