后缀匹配 LIKE '%keyword' 一定走全表扫描，因B+树索引仅支持左前缀匹配；唯一纯MySQL解法是字符串反转+单独建索引，需同步维护反转列、在反转列建索引、查询时对关键词反转且用前缀匹配。
后缀匹配 LIKE '%keyword' 一定走全表扫描，没法绕开——这不是写法问题，是 B+ 树索引结构决定的硬限制。唯一实用、可控、纯 MySQL 的解法，就是字符串反转 + 单独建索引。
为什么 LIKE '%keyword' 永远不走索引
B+ 树索引按字典序从左到右排序，只支持“从开头匹配”。LIKE '%keyword' 要求定位末尾字符，优化器根本找不到扫描起点，只能放弃索引，退化为 type: ALL。哪怕字段上已有 INDEX idx_name (name)，执行 EXPLAIN SELECT * FROM t WHERE name LIKE '%abc'，key 列也一定是 NULL。
怎么建反转列并让查询真正走索引
核心是把“后缀问题”转成“前缀问题”，但必须严格对齐存储与查询逻辑：
HR面试评价助手-Word版
下载
🎯 HR面试评价助手（Word版格式） 生成可直接复制到Word文档的标准格式HR面试评价 【使用方式】 1. 发送口令：HR面试评价 2. 粘贴JD文字 3. 上传简历文档 4. 上传面试记录（可选） 5. 复制生成的评价到Word 【输出特点】 - 纯文本格式，可直接粘贴到Word - 层次清晰，标题加粗...
- 新增列存反转值：
ALTER TABLE users ADD COLUMN email_reversed VARCHAR(255) - 用触发器自动维护（推荐）：
BEFORE INSERT/UPDATE中写SET NEW.email_reversed = REVERSE(NEW.email)，避免应用层漏更新 - 索引必须建在反转列上：
CREATE INDEX idx_email_rev ON users(email_reversed)；建在原字段email上完全无效 - 查询时，搜索词也要反转，且去掉左侧
%：WHERE email_reversed LIKE 'erriep%'（不是'%erriep'，更不能写REVERSE(email) LIKE '%erriep'）
常见翻车点：反转了但还是慢
线上最常出错的不是不会建，而是细节错位：
- 查询条件写成
email_reversed LIKE '%erriep'—— 又变回后缀匹配，索引失效 - 在
WHERE子句里对列用函数：WHERE REVERSE(email) LIKE 'erriep%'—— 函数作用于列，无法命中索引 - 大小写不统一：
REVERSE('Pierre')是'erriep'，REVERSE('pierre')是'erriep'，但若排序规则是utf8mb4_0900_as_cs，两者不等价，查不到 - 反转列长度超长（如原始字段 500 字符），B+ 树索引深度增加，
range扫描实际性能下降明显
这个方案不适合什么场景
它轻量、不引入外部依赖，但边界清晰：
- 不支持中缀模糊：
LIKE '%abc%'无法通过单次反转解决 - 不处理中文分词：
REVERSE('张三')是'三张'，搜“张”或“三”仍得全表扫 - 高并发写入下，触发器带来额外开销，且必须确保和主字段在同一事务中更新，否则数据不一致
真正难的不是加一列、建一个索引，而是所有环节——插入逻辑、查询写法、字符集配置、大小写策略——必须严丝合缝对齐，漏掉任意一环，索引就形同虚设。
