like 'abc%' 能走索引，前提是字段有匹配的b+树索引且无类型不匹配、隐式转换或函数包裹；而like '%abc'或'%abc%'必然全表扫描，此时应改用反向索引或fulltext。
LIKE 'abc%' 能走索引，但必须满足这个前提
只有 LIKE 'abc%' 这类固定前缀形式才能触发 B+ 树索引的范围扫描。MySQL 会把它转成 name >= 'abc' AND name 这样的区间查询，真正利用索引有序性。
常见错误是字段没建索引，或建了但类型不匹配：比如 username 是 VARCHAR(255)，但用了 TEXT 类型——TEXT 字段默认不能直接建普通索引，得加前缀长度。
- 确认索引存在：
SHOW INDEX FROM users WHERE Key_name = 'idx_username'; - 避免隐式转换：如果
username的 collation 是utf8mb4_0900_as_cs（大小写敏感），而查询字面量用的是小写'ABC%'，可能因排序规则不一致导致索引失效 - 前缀索引要够长：比如姓名字段平均长度 12，但前 5 个字符大量重复（如“张伟”“张磊”“张敏”），
INDEX(username(5))就失去区分度，得拉到(10)或更高
LIKE '%abc' 或 '%abc%' 必然全表扫描，别硬扛
只要模式以 % 开头，优化器就无法定位起始位置，EXPLAIN 里一定会看到 type: ALL 和 key: NULL。这不是配置问题，是 B+ 树结构决定的硬限制。
这时候继续在 LIKE 上调参毫无意义。真实业务中常犯的错是：加了索引还慢，就以为是索引没建好，反复试前缀长度、换 collation，结果还是 ALL。
- 别用
UPPER()、LOWER()包裹字段：WHERE UPPER(username) LIKE '%abc%'—— 函数调用直接让索引失效 -
REGEXP更慢，且完全不走索引，比LIKE还差一个数量级 - 如果必须支持后缀匹配（如查“以‘有限公司’结尾”），优先考虑冗余字段：
company_suffix存最后 10 个字符，再对它建索引
MySQL 8.0+ 可用反向索引绕过前导通配符
核心思路是把数据反转存、查询也反转写，把 LIKE '%abc' 变成 LIKE 'cba%'。这依赖生成列 + 函数索引能力，不是所有版本都支持。
实操分三步：先加生成列，再建索引，最后改查询。注意生成列必须是 STORED，否则无法索引。
- 添加反转列：
ALTER TABLE users ADD COLUMN username_rev VARCHAR(50) GENERATED ALWAYS AS (REVERSE(username)) STORED; - 建索引：
CREATE INDEX idx_username_rev ON users(username_rev); - 查后缀：
SELECT * FROM users WHERE username_rev LIKE REVERSE('%有限公司');→ 实际执行等价于username_rev LIKE '限公司有%'
这个方案对单字段后缀匹配有效，但 LIKE '%abc%'（中间模糊）仍不行；而且每行多存一份反转值，写入开销略增。
FULLTEXT 是更通用的替代方案，但要用对模式
FULLTEXT 不是“给 LIKE 加速”，它是另一套索引机制（倒排索引），专为文本检索设计。性能差距不是几倍，而是数量级提升——尤其在百万级以上数据时。
容易踩的坑是中文支持和布尔模式语法。MySQL 原生对中文分词支持弱，innodb_ft_min_token_size 默认是 3，意味着“张三”这种两字词根本进不了索引。
- 建索引前确认引擎：
SHOW CREATE TABLE users;，如果不是INNODB，先执行ALTER TABLE users ENGINE = INNODB; - 中文需调小分词粒度：
SET GLOBAL innodb_ft_min_token_size = 1;（重启后生效），或应用层预分词后存入独立字段 - 查询必须用
MATCH() AGAINST()，不能混用WHERE ... LIKE；AGAINST()里不能拼接变量，参数必须是字符串字面量
真正难的不是怎么建，而是判断该不该用：如果业务需要相关性排序、支持“张三李四”语义搜索、容忍少量延迟（全文索引有更新延迟），FULLTEXT 就比死磕 LIKE 合理得多。
