前缀匹配（LIKE 'abc%'）能走索引但查询仍慢，因前缀过短或选择性低导致扫描行数过多；需结合高选择性条件、覆盖索引、LIMIT及合适字符集优化。
前缀匹配（LIKE 'abc%'）本身能走索引，但数据量大时仍会卡顿——问题不在“能不能用索引”，而在“用了索引后扫了多少页、回了多少行”。
为什么 EXPLAIN 显示用了索引，查询却还是慢？
常见错误现象：type=range、key=idx_name 看起来正常，但 rows 值高达几十万，甚至接近全表；Extra 里出现 Using where; Using index 或更糟的 Using filesort 或 Using temporary。
根本原因不是索引没建，而是前缀太短或选择性太低：比如用户刚输一个“李”，LIKE '李%' 可能命中上万条记录，B+ 树虽定位到起始页，但仍要顺序遍历大量索引节点 + 回表取数据。
- 前缀越短（如 1~2 字符），索引扫描范围越大，IO 和 CPU 开销直线上升
- 字段字符集影响显著：
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，且确保LIMIT值远小于预估匹配数；否则优化器可能放弃索引，改走全表（尤其当统计信息过期时） - 避免在
LIKE字段上做隐式转换：比如列是VARCHAR(100)，但传参是CHAR(50)，可能导致索引失效；统一用CONVERT(... USING utf8mb4)显式转码
前缀索引（INDEX(col(n))）该不该用？
只在字段特别长（如 TEXT 或超长 VARCHAR）、且绝大多数查询前缀长度稳定时才考虑。否则容易踩坑。
- 前缀长度必须覆盖真实查询模式：执行
SELECT COUNT(DISTINCT LEFT(name, 10)) / COUNT(*) FROM users;，若结果 name(10) 索引几乎无效 -
LIKE 'abcdefghij%'能用name(10)索引，但LIKE 'abcdefghijk%'就完全失效——索引只认前 10 位 - 前缀索引无法支撑
ORDER BY name或GROUP BY name，除非语句里只用到前缀部分（如ORDER BY LEFT(name, 10)） - 不要为
name建name(20)索引，又为email建email(50)索引——每个前缀索引都是独立 B+ 树，内存和磁盘开销叠加很快
搜索补全类场景的轻量替代方案
如果业务是“用户每输一个字就查一次补全列表”，原生 LIKE 'xxx%' 在百万级表上极易成为瓶颈，因为每次请求都在扫索引区间，且无法复用中间结果。
- 用生成列 + 函数索引（MySQL 8.0+）：添加
name_prefix VARCHAR(10) GENERATED ALWAYS AS (LEFT(name, 10)) STORED，再建普通索引INDEX idx_name_prefix (name_prefix)；查询时直接WHERE name_prefix = '张三丰'，彻底规避模糊匹配 - 缓存高频前缀：应用层维护 Redis 中的
prefix:张 → ["张三", "张无忌", "张翠山"]，更新时异步刷新；对冷门前缀再 fallback 到数据库 - 注意
INFORMATION_SCHEMA.STATISTICS中的索引统计可能滞后，定期跑ANALYZE TABLE users;，尤其在大批量导入后
真正难的不是“怎么让 LIKE 走索引”，而是“怎么让走了索引的查询，少读几页、少回几行、少排几次序”。索引只是起点，不是终点。
