能，前提是字段上有B+树索引且无干扰因素；LIKE 'abc%'等价于范围查询，可定位起始位置并顺序遍历，而'%abc'因无法确定起点只能全表扫描。
LIKE 'abc%' 真的能走索引吗？先看 EXPLAIN
能，但前提是字段上有 B+ 树索引，且查询没被其他因素干扰。很多同学加了 INDEX(name) 就以为万事大吉，结果 EXPLAIN SELECT * FROM users WHERE name LIKE '张%' 显示 type: ALL，说明根本没走索引。常见干扰项包括：
• 字段类型和参数类型不一致，比如 name VARCHAR(50) 却跟整数比较：WHERE name LIKE 123
• 在字段上用了函数：WHERE UPPER(name) LIKE 'ABC%'（可建函数索引：CREATE INDEX idx_name_upper ON t1 ((UPPER(name)))）
• 查询含 OR 且分支之一无索引：WHERE name LIKE 'a%' OR status = 1，优化器可能直接放弃索引
• 表太小或匹配行太多（>20% 总行数），优化器认为全表扫描更快——这时 rows 值会异常高，但 type 仍是 ALL
为什么只允许右模糊？B+ 树不是“树”而是“有序链”
MySQL 的 B+ 树索引本质是按字典序排好的线性结构，支持高效范围查找，但不支持“从中间跳”。LIKE 'abc%' 等价于 name >= 'abc' AND name ，优化器能快速定位到第一个 <code>'abc' 开头的位置，然后向右扫一段；而 LIKE '%abc' 没有起点，只能从头扫到尾。
• LIKE '张三%' → 可走索引，只要 name 有索引
• LIKE '张_丰' → 下划线只占一位，前缀连续，仍可定位起始位置
• LIKE '张%丰' → 中间带 %，B+ 树无法跳过未知长度段继续比对，索引失效
• LIKE '张三丰 '（尾部空格）→ 若实际数据存的是 '张三丰'，因 collation 默认忽略尾部空格，可能命中；但若用 utf8mb4_0900_as_cs 这类严格排序规则，则不等价，查不到
索引怎么建才真正生效？别只建单列索引
单列索引 INDEX(name) 对 SELECT id, name FROM users WHERE name LIKE '李%' 是够用的，但如果查的是 SELECT id, name, email FROM users WHERE name LIKE '李%'，InnoDB 就得回表取 email，性能打折扣。这时候该上覆盖索引：
• 建复合索引：CREATE INDEX idx_name_email ON users (name, email)
• 注意顺序：name 必须在前，因为它是 WHERE 条件；email 放后，让查询无需回表
• 如果还要查 status 和 created_at，就扩展为 (name, email, status, created_at)，但别无脑堆字段——索引越宽，写入开销越大，且超出 1000 字节可能被截断
• 对长文本字段（如 TEXT），必须指定前缀长度：INDEX idx_title_20 (title(20))，否则建索引失败
参数拼接时 % 到底该放哪？ORM 里最容易翻车
MyBatis、JDBC 或 Django ORM 都要求通配符必须出现在参数值里，不能写死在 SQL 模板中。否则预编译会把 % 当普通字符处理，导致查不到数据。
• ❌ 错误写法：WHERE name LIKE '%#{keyword}%' → MyBatis 把 % 当字面量，实际查的是字面含 % 的字符串
• ✅ 正确写法一：WHERE name LIKE #{keyword}，Java 侧传入 "%张%"（注意：这是后缀模糊，不走索引）
• ✅ 正确写法二（推荐前缀模糊）：WHERE name LIKE #{keyword}，Java 传入 "张%"
• ✅ 正确写法三（兼容特殊字符）：如果 keyword 本身含 _ 或 %（如查文件名 report_2024.sql），必须先 escape：keyword.replace("_", "\_").replace("%", "\%")，再配合 ESCAPE '' 子句：WHERE name LIKE #{keyword} ESCAPE ''
真正难的不是“怎么加索引”，而是判断业务是否真的适合用 LIKE 'xxx%'。一旦出现 LIKE '%xxx' 或 LIKE '%xxx%'，哪怕加了索引也白搭——这时候该考虑 FULLTEXT + ngram，或者提前在应用层生成反向字段做前缀查，而不是硬扛。
