like 'abc%'能走索引需同时满足：字段为varchar/text等可索引类型、索引已正确创建（含前缀索引长度合理）、排序规则匹配且查询无函数包裹或中间通配符，否则即使建索引也无效。
前缀通配符（即 LIKE 'abc%' 这类写法）本身就能走索引，但“能走”不等于“真走”——很多情况下加了索引也白搭。关键是要满足三个硬性条件，缺一不可。
字段类型和索引定义要匹配
必须是 VARCHAR、TEXT 或带长度限制的字符串类型；CHAR 类型因自动补空格，容易导致意外不匹配（比如 LIKE 'abc%' 查不到实际存为 'abc ' 的值）。建索引时别漏掉：
- 普通字段直接建：
CREATE INDEX idx_name ON users(name); - 长字段（如
VARCHAR(255)）建议用前缀索引：CREATE INDEX idx_title_15 ON articles(title(15)); - 前缀长度不是拍脑袋定的，可用
COUNT(DISTINCT LEFT(name, N)) / COUNT(*)测区分度，建议 >0.9
排序规则（collation）不能破坏匹配语义
大小写敏感的 collation（如 utf8mb4_0900_as_cs）会让 WHERE name LIKE 'Abc%' 无法命中普通索引，因为索引里存的是小写或二进制顺序。解决办法有两个：
- 统一用小写查：
WHERE name LIKE 'abc%' - 显式指定 collation：
WHERE name COLLATE utf8mb4_general_ci LIKE 'Abc%'
注意：如果字段本身用的是 _ci（case-insensitive）规则，那大小写就天然不敏感，不用额外处理。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
查询模式必须真正“有确定前缀”
只有最左连续部分完全固定，B+ 树才能定位起始位置。以下写法看似像前缀，实则失效：
-
name LIKE '张%丰'→ 中间有%，跳不过去，索引失效 -
name LIKE '张_三'→_是单字符通配，只要前面有固定字（如‘张’），仍可走索引 -
UPPER(name) LIKE 'ABC%'→ 字段被函数包裹，索引失效（MySQL 8.0+ 可建函数索引：CREATE INDEX idx_name_upper ON t1 ((UPPER(name)))） -
name LIKE ?（参数化查询）→ 没问题，但传入的值不能以%开头
优化器没主动放弃索引
即使满足以上所有条件，MySQL 也可能因成本估算放弃索引。常见触发场景：
- 匹配行数太多（比如
LIKE 'A%'返回 40% 的数据），优化器认为全表扫描更快 - 表很小（几百行），索引访问开销反而更高
- 查询涉及回表且覆盖不足，比如
SELECT *但索引只含name，就得反复读聚簇索引
这时可考虑覆盖索引：CREATE INDEX idx_name_email ON users(name, email);，让常用字段一并带上，避免回表。
