能，因为b+树索引按字典序排序，like 'abc%'等价于name >= 'abc' and name

LIKE 'abc%' 能走索引吗？

能，但前提是字段上有 B-tree 索引，且 LIKE 模式以固定字符串开头、不以通配符起始。MySQL、PostgreSQL、SQL Server 都支持这种左前缀匹配走索引；而 LIKE '%abc' 或 LIKE '%abc%' 无法使用常规 B-tree 索引（除非配合全文索引或倒排索引）。

• 必须是 WHERE column LIKE 'prefix%' 形式，不能有前导 %
• 字段类型需与索引定义一致（例如 VARCHAR 字段建了索引，查询时别用 CHAR 隐式转换）
• MySQL 中若列启用了 utf8mb4_unicode_ci 这类排序规则，LIKE 仍可走索引，但大小写不敏感匹配不影响索引使用
• PostgreSQL 对 text 字段建普通 B-tree 索引后，LIKE 'abc%' 同样生效；但 ILIKE 在无额外操作符类（如 text_pattern_ops）时可能不走索引

为什么 LIKE 'abc%' 有时没走索引？

常见原因是隐式类型转换或函数包裹导致索引失效。比如字段是 INT 类型却写成 WHERE col LIKE '123%'，数据库会尝试把整数转字符串再匹配，索引就断了；又或者加了 UPPER()、TRIM() 等函数，直接让索引不可用。

• 检查执行计划：EXPLAIN SELECT ...，确认 key 列非 NULL，type 是 range 或 ref
• 避免在索引列上做任何计算：WHERE UPPER(name) LIKE 'ABC%' → 改为 WHERE name LIKE 'ABC%' 并确保大小写策略合理
• MySQL 中若字段定义为 VARCHAR(255) 但实际只存短字符串，LIKE 'a%' 可能因统计信息不准被优化器误判为全表扫描，可加 FORCE INDEX 验证

PostgreSQL 怎么让 LIKE 'abc%' 更稳地走索引？

默认 B-tree 索引支持前导匹配，但对非 C 排序规则（如 en_US.UTF-8）下的 LIKE，PostgreSQL 实际依赖操作符族 text_pattern_ops。不显式指定时，某些 locale 下可能退化为顺序扫描。

• 建索引时明确指定：CREATE INDEX idx_name ON tbl (col text_pattern_ops);
• text_pattern_ops 不支持多字节排序语义（比如德语 ß 视为 ss），仅用于纯前缀匹配场景，无需排序或范围比较
• 如果同时需要排序 + 前缀查询，可建两个索引：一个默认 B-tree（用于 ORDER BY），一个带 text_pattern_ops（专供 LIKE 'xxx%'）

MySQL 的前缀索引和 LIKE 有什么关系？

前缀索引（如 INDEX(col(10))）本身不是为 LIKE 设计的，但它会影响 LIKE 'abc%' 是否命中索引——因为索引只存前 10 个字符，如果查询模式长度超过前缀长度（如 LIKE 'abcdefghij%'），即使满足左前缀形式，也可能因索引内容不全而无法精确定界。

• 前缀索引长度必须 ≥ 查询中固定前缀长度，否则 range 扫描可能变 index 全索引扫描
• 用 SHOW INDEX FROM tbl 查看 Sub_part 列，确认是否为 NULL（表示全列索引）或具体数字
• 不建议对高基数字符串字段盲目设短前缀索引；LIKE 'a%' 在 INDEX(col(1)) 上虽能走索引，但区分度极差，实际性能未必好

真正卡住性能的往往不是语法会不会，而是执行计划里那个没出现的 key，以及你没意识到 CONCAT() 或参数绑定时的类型隐式转换已经悄悄绕开了索引。