LIKE模糊查询在Navicat中没走索引，是因为MySQL执行计划显示type=ALL或key=NULL，主因是前导通配符（如'%abc'）、全模糊（'%abc%'）、函数操作、隐式类型转换或字符集不一致导致B+树索引失效。
为什么 LIKE 模糊查询在 Navicat 里显示没走索引
Navicat 的「执行计划」（Explain）本身不决定是否走索引，它只是展示 MySQL 实际执行时的策略。你看到 type=ALL 或 key=NULL，说明 MySQL 确实没用索引——但原因往往不是 Navicat 的问题，而是 LIKE 表达式写法触发了全表扫描。
常见诱因包括：
-
LIKE '%abc'（前导通配符）：B+ 树索引无法从左匹配，必然放弃使用索引 -
LIKE '%abc%'（前后通配符）：同样无法利用索引的有序性 - 字段用了函数或表达式，比如
LOWER(name) LIKE '%x%'，导致索引失效 - 索引列类型和查询参数类型不一致，例如
name VARCHAR(50)被传入INT值，引发隐式转换
在 Navicat 中正确查看执行计划的步骤
别直接点「运行」，要确保看到的是真实执行路径：
- 右键目标查询 → 选择「解释」（Explain），或按快捷键
Ctrl+Shift+E（Windows）/Cmd+Shift+E（macOS） - 检查结果中
key列是否为NULL；若为NULL，说明没命中索引 - 关注
type列：ALL是全表扫描，range或ref才算有效利用索引 - 注意
possible_keys是否包含你预期的索引名——如果连候选都没有，可能是索引建错列或被忽略了
小技巧：在 Navicat 查询编辑器中，把语句改成 EXPLAIN FORMAT=TRADITIONAL SELECT ... 再执行，能获得更清晰的文本结构。
LIKE 能走索引的几种安全写法
只有满足“左对齐、无前置通配符”才可能触发索引扫描：
-
WHERE name LIKE 'abc%'✅ 可走索引（B+ 树前缀匹配） WHERE name >= 'abc' AND name ✅ 等价写法，明确提示优化器走范围扫描-
WHERE name LIKE 'abc\_def%'✅ 下划线只占一位，仍属前缀匹配 -
WHERE name LIKE 'abc%' ESCAPE '\'✅ 显式声明转义符，避免误判
注意：LIKE 'abc%' 对应的索引必须是 (name) 或以 name 为最左前缀的联合索引（如 (name, status)）。如果建的是 (status, name)，这个查询依然不会走索引。
容易被忽略的底层影响因素
即使写法合规，也可能因以下原因绕过索引：
- MySQL 认为全表扫描比索引回表更快（比如表很小，或匹配行数 > 总行数 20% 左右），会主动放弃索引
- 字符集/排序规则不一致，例如字段是
utf8mb4_0900_as_cs，而连接默认用utf8mb4_general_ci，导致无法做索引比较 - 使用了覆盖索引但字段太多，MySQL 评估成本后弃用（可通过
SELECT *vsSELECT id,name对比执行计划验证） - Navicat 默认开启「自动提交」且连接复用，某些缓存行为可能让执行计划看起来“没刷新”，可尝试断开重连或加
SELECT SLEEP(0)强制重新解析
真正卡住的地方，往往不在 LIKE 本身，而在索引定义、数据分布、连接配置这三者的交叉作用上。
