INSTR函数无法替代LIKE实现索引加速，它和LIKE '%xxx%'一样必然触发全表扫描；真正能提速的是全文索引、前缀匹配或反向索引等结构性优化。
直接说结论：INSTR 函数无法替代 LIKE 实现索引加速，它和 LIKE '%xxx%' 一样必然触发全表扫描；真正能提速的只有全文索引、前缀匹配或反向索引这类结构性优化手段。
为什么 INSTR(col, 'xxx') 比 LIKE '%xxx%' 还慢？
INSTR 是字符串查找函数，MySQL 必须对每一行的 col 值完整计算一次位置，无法下推到索引层。而 LIKE '%xxx%' 至少还有可能被优化器识别为可短路的模式（虽然仍走全表），INSTR 则完全绕过所有索引机制。
- 执行计划里
type一定是ALL，Extra字段不会出现Using index condition - 如果字段是
TEXT或超长VARCHAR，INSTR还会额外触发隐式转换或临时表，CPU 开销更高 - 用
INSTR写模糊查询，等于主动放弃所有索引可能性——这不是“换种写法”，而是降级为纯内存扫描
哪些 LIKE 场景能走索引？关键看通配符位置
只有满足“前缀匹配”这一条件时，B+树索引才有效。不是“有没有索引”，而是“查询模式是否匹配索引组织方式”。
-
WHERE name LIKE '张%'→ 可走普通 B-tree 索引，type = range -
WHERE name LIKE '张三%'→ 同样有效，但要注意字符集：若用utf8mb4_0900_as_cs，LIKE '张三%'不会命中'张三丰'（大小写/重音敏感） -
WHERE name LIKE '%张'→ 即使建了索引也无效，必须改用反向索引：REVERSE(name)字段加索引，再查REVERSE(name) LIKE REVERSE('%张') -
WHERE name LIKE '%张%'→ 无解，B-tree 索引天生不支持中缀匹配；别试图用函数索引包裹INSTR或SUBSTRING，MySQL 8.0 的函数索引只支持确定性、无副作用的表达式
全文索引不是“备选方案”，而是后缀/中缀模糊的唯一合理出路
当业务明确需要“包含任意词”“多关键词组合”或“相关性排序”时，FULLTEXT 不是优化技巧，而是技术选型分水岭。
- MySQL 的
MATCH(col) AGAINST('xxx' IN BOOLEAN MODE)支持+、-、*（词干通配），且底层是倒排索引，与LIKE完全不同量级 - 创建时注意：仅
InnoDB和MyISAM支持，且字段需为CHAR/VARCHAR/TEXT；CREATE FULLTEXT INDEX不能和普通索引合并语句写在一起 - 避免踩坑：
AGAINST('xxx')默认是自然语言模式，对短词（AGAINST('+xxx*' IN BOOLEAN MODE) - PostgreSQL 用户请直接用
tsvector+@@操作符，配合zhparser插件处理中文分词，比 MySQL 全文索引更可控
真正容易被忽略的性能断点：不是 SQL 写法，而是数据访问路径
很多人花几小时调 LIKE 写法，却没意识到瓶颈在回表或 IO 层。比如：
- 查
SELECT *+LIKE 'abc%'，即使走了索引，若name字段只占索引的 10%，其余 90% 字段要靠回表读聚簇索引，磁盘随机 IO 成倍增加 - 高频模糊查询（如搜索框 autocomplete）应前置缓存
keyword → [id1,id2]，Redis 里用ZSET存带权重的结果，比每次查 DB 快两个数量级 - 日志类场景（如
log_content LIKE '%error%'）根本别碰关系库，用ClickHouse的positionCaseInsensitive或Elasticsearch的match_phrase才是正解
