LIKE '%xxx' 必然全表扫描，因B+树索引依赖前缀可确定性，无法支持后缀匹配；可行解只有换索引类型（如全文索引）或换查询方式（如前缀匹配、ES等外部引擎）。
LIKE '%xxx' 一定用不上普通 B+ 树索引，这不是配置或写法问题，是 MySQL 索引结构决定的硬限制。 想靠改 WHERE 条件、加提示（hint）或调优统计信息绕过，基本没用。真正可行的路只有两条：换索引类型，或者换查询方式。
为什么 LIKE '%xxx' 必然全表扫描
B+ 树索引按字典序存储，查找依赖“前缀可确定性”。LIKE 'xxx%' 能定位起始位置再向右遍历；而 LIKE '%xxx' 需要检查每个值是否“结尾含 xxx”，索引无法跳过无关数据。执行 EXPLAIN 时 key 列一定是 NULL，type 是 ALL。
常见误判点：
- 以为加了复合索引（比如
(status, name)）就能救 —— 没用，只要name上是左模糊，该字段在索引中就完全不可用 - 以为把
WHERE name LIKE '%xxx'改成WHERE name REGEXP 'xxx$'就能走索引 —— 不行，正则同样不支持后缀索引 - 忽略字符集影响：如果列是
utf8mb3但存了 4 字节 emoji，LIKE可能因截断或比较失败导致意外空结果，看起来像“失效”，实则是匹配逻辑出错
用全文索引替代 LIKE 的实操要点
适合字段内容较长（如文章标题、商品描述）、且搜索词不固定、需相关性排序的场景。不是所有模糊需求都适用，但对“包含某词”类查询最直接。
必须注意：
- 创建前确认 MySQL 版本 ≥ 5.6，且存储引擎是
MyISAM或InnoDB（InnoDB 全文索引从 5.6 开始支持） - 全文索引只对
CHAR、VARCHAR、TEXT有效，不能建在INT或带函数的表达式上 - 语法必须用
MATCH ... AGAINST，不能混用LIKE：MATCH(name) AGAINST('xxx' IN NATURAL LANGUAGE MODE) - 默认停用词（如“的”、“和”、“in”）不会被索引，短词（
ft_min_word_len默认 4）也搜不到，需调整配置并重建索引
示例：
ALTER TABLE articles ADD FULLTEXT(title, content);
SELECT * FROM articles WHERE MATCH(title) AGAINST('数据库优化' IN NATURAL LANGUAGE MODE);覆盖索引对 LIKE '%xxx' 完全无效，别试
覆盖索引（Covering Index）只能减少回表，前提是索引本身能先定位到记录。而 LIKE '%xxx' 连第一步“定位”都做不到，覆盖再多字段也没意义。你看到的“用了索引”其实是其他条件（比如 WHERE status = 1 AND name LIKE '%xxx' 中的 status）带来的假象 —— name 部分仍是全表扫描。
真正能缓解性能的，是提前过滤：
- 加高选择性等值条件（如
AND created_at > '2026-01-01'），缩小扫描范围 - 用分区表按时间/状态切分，让扫描只发生在某个分区
- 业务层缓存高频后缀查询结果（如“以‘科技’结尾的公司名”），避免反复扫
更现实的替代方案：倒排或外部搜索引擎
如果业务真需要高频、低延迟、任意位置的中文模糊匹配（比如用户搜索框输入实时补全），MySQL 原生能力已到极限。这时候该考虑：
- 用
LIKE 'xxx%'+ 前缀树（Trie）预生成所有可能后缀，查表映射 —— 适合后缀集合有限的场景（如固定行业词尾） - 导出数据到
Elasticsearch或Meilisearch，用ngram分词器支持子串检索，延迟可控在毫秒级 - 对小表（str.endswith() 或
re.search()），比 MySQL 扫更快
最后提醒一句：别在生产环境反复 EXPLAIN 一个 LIKE '%xxx' 查询还期待它“突然变快”。方向错了，调参没用。判断是否该换技术栈，比优化单条 SQL 更重要。
