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在什么条件下连索引都懒得用——尤其是带前导通配符、套了函数、或者匹配基数太高时，优化器早就默默放弃了。
