能走索引的只有 like 'abc%'，其他形式如 '%abc' 或 '%abc%' 必然全表扫描；即使 explain 显示 type=range、key 有效，若 rows 值巨大且 extra 含 using where，根源在于前缀过短或选择性低导致扫描行数过多，需通过高选择性前置条件、覆盖索引、limit 及合适字符集优化。
能走索引的只有 LIKE 'abc%'，其他形式基本没戏——别在 LIKE '%abc' 上硬调索引，该换方案就换。
为什么 EXPLAIN 显示用了索引但还是慢？
常见错误现象：type=range、key=idx_name 看起来正常，但 rows 值几十万，Extra 里出现 Using where; Using index 甚至 Using filesort。
- 根本不是索引没建，而是前缀太短或字段选择性低：比如
LIKE '李%'在百万用户表里可能命中 5 万行，B+ 树定位起始页后仍要顺序遍历大量索引节点 + 回表 -
utf8mb4_unicode_ci这类排序规则会让“李”“裏”“礼”等字在索引中相邻，进一步扩大扫描范围；换成utf8mb4_bin可提升区分度（但得确认业务是否允许大小写敏感） - 如果带
ORDER BY name或LIMIT 10，MySQL 无法提前终止扫描——它得先把所有匹配项找出来，再排序截断
怎么让 LIKE 'abc%' 真正快起来？
核心是减少实际扫描行数，不是单纯加索引。
- 加高选择性前置条件：比如
WHERE status = 1 AND name LIKE '张%'，先用status快速筛掉 90% 数据，再对小结果集做前缀匹配 - 用覆盖索引避免回表：把常用查询字段放进联合索引，例如
CREATE INDEX idx_name_status_id ON users(name, status, id)，这样SELECT id, status FROM users WHERE name LIKE '张%'就能直接从索引取值 -
LIMIT必须加，且值要远小于预估匹配数；否则优化器可能放弃索引改走全表（尤其统计信息过期时） - 避免隐式转换：比如列是
VARCHAR(100)，传参却是CHAR(50)，可能导致索引失效；统一用CONVERT(... USING utf8mb4)显式转码
LIKE '%abc' 和 LIKE '%abc%' 怎么办？
它们注定不走 B+ 树索引，继续调索引参数毫无意义。
- 查后缀（如
'%有限公司'）：用生成列 + 反向索引，MySQL 5.7.6+ 支持：ALTER TABLE users ADD COLUMN name_rev VARCHAR(50) GENERATED ALWAYS AS (REVERSE(name)) STORED;<br>CREATE INDEX idx_name_rev ON users(name_rev);<br>SELECT * FROM users WHERE name_rev LIKE REVERSE('%有限公司'); - 查中间子串（如
'%数据库%'）：FULLTEXT是更现实的选择，但注意：INNODB_FT_MIN_TOKEN_SIZE默认为 4，搜 “AI” 或 “李” 会被忽略；中文必须配WITH PARSER ngram，且只能用MATCH() AGAINST()，不能混用LIKE -
INSTR()、LOCATE()、REGEXP都不提速，执行计划仍是type: ALL，只是语义更直白而已
前缀索引到底要不要用？
只在字段特别长（如 TEXT 或超长 VARCHAR）、且绝大多数查询前缀长度稳定时才考虑。
- 前缀长度必须覆盖真实查询模式：
SELECT COUNT(DISTINCT LEFT(name, 10)) / COUNT(*)若低于 0.95，说明name(10)区分度不够 -
LIKE 'abcdefghijk%'在name(10)索引上完全失效——索引只认前 10 位 - 前缀索引无法支撑
ORDER BY name或GROUP BY name，联合索引里如果把前缀列放后面（如(status, username(10))），LIKE 'xxx%'依然用不上
最容易被忽略的点是：模糊查询慢，往往不是因为“没建对索引”，而是因为“用了索引却扫了太多行”。盯着 rows 和 Extra 看，比反复试前缀长度管用得多。
