LIKE以通配符开头时索引完全失效，如'%abc'或'%abc%'导致全表扫描；仅前缀匹配'abc%'可走索引；函数包裹、低区分度前缀、中文排序规则等也影响索引使用。
LIKE 以通配符开头时索引完全失效
当 WHERE name LIKE '%abc' 或 WHERE name LIKE '%abc%' 这类查询出现时，MySQL 无法使用 B+ 树索引的有序性，会退化为全表扫描。哪怕 name 字段上有索引，执行计划里 key 列也会显示 NULL。
- 唯一能走索引的
LIKE形式是前缀匹配：WHERE name LIKE 'abc%'（注意结尾是%，开头无通配符） - 如果业务必须支持前后模糊搜索，优先考虑全文索引（
FULLTEXT）或引入 Elasticsearch / Meilisearch 等专用搜索服务 -
LIKE '_abc'（单下划线）同样无法走索引，因为下划线代表任意单字符，MySQL 仍无法定位起始范围
用函数或表达式包裹列会导致索引失效
写成 WHERE UPPER(name) LIKE 'ABC%' 或 WHERE CONCAT('%', 'abc') = name，即使逻辑等价于前缀匹配，索引也用不上——MySQL 不会对表达式结果建索引（除非你显式创建函数索引）。
- MySQL 8.0+ 支持函数索引：
CREATE INDEX idx_name_upper ON users ((UPPER(name)));
但需确保查询中函数与索引定义完全一致 - 更稳妥的做法是：在写入时就存一份规范化的字段（如
name_upper），查询直接走该字段的普通索引 - 避免在
LIKE左侧使用任何函数、计算或列拼接
LIKE 匹配长度过短时优化器可能放弃索引
即使写成 WHERE name LIKE 'a%'，如果表中以 a 开头的值占比超过约 20%～30%，MySQL 优化器会判断走索引反而更慢，主动选择全表扫描。这在用户昵称、城市名等低区分度字段上很常见。
- 用
EXPLAIN查看rows和key字段确认是否真用了索引 - 用
SELECT COUNT(*) FROM t WHERE name LIKE 'a%'估算匹配比例；若过高，说明该前缀区分度过低，索引价值有限 - 可尝试组合索引：比如
(status, name)，把高区分度字段放前面，让索引过滤更有意义
中文分词和排序规则影响 LIKE 行为
MySQL 对中文的 LIKE 匹配依赖字符集和排序规则。例如 utf8mb4_general_ci 不区分大小写且忽略某些 Unicode 变体，但不支持真正的中文分词；而 utf8mb4_0900_as_cs 区分大小写和重音，可能导致预期外的不匹配。
- 检查字段排序规则：
SHOW FULL COLUMNS FROM users LIKE 'name';关注Collation列 - 中文前缀搜索建议统一用
utf8mb4_unicode_ci或更高版本的排序规则，兼顾兼容性和准确性 - 不要依赖
LIKE做中文“包含”语义搜索（如查“苹果手机”是否含“果”），它只做字节/字符级匹配，不是语义搜索
LIKE 在什么条件下连索引都懒得用——尤其是带前导通配符、套了函数、或者匹配基数太高时，优化器早就默默放弃了。 
