INSTR并不比LIKE快，仅在前后通配匹配或需定位第N次出现时更实用；它无法使用B-tree索引（除非MySQL 8.0+函数索引），且不支持词边界匹配。
INSTR比LIKE '%keyword%' 更快，但仅限特定场景
INSTR函数本身不加速查询，它只是把“是否包含”转化为“位置是否大于0”的数值判断。真正起作用的是：当字段有前缀索引且关键词固定在开头时，LIKE 'keyword%'能走索引，而INSTR(field, 'keyword') > 0在任何位置匹配都**无法使用B-tree索引**——除非你用的是MySQL 8.0+的函数索引，且显式创建了INDEX idx_instr ON t ((INSTR(name, '张')))这类表达式索引。
所以别迷信“INSTR一定比LIKE快”。它只在两类情况更实用：
- 必须做前后通配匹配（如
'%张%李%'），又不想上全文索引时，INSTR写法更直观、可读性略高 - 需要区分“第一次出现位置”或“第N次出现”，比如提取第二个分隔符后的子串，这时
INSTR(str, '|', 1, 2)是唯一选择
多关键字OR组合用INSTR，性能反而可能更差
写INSTR(description, '手机') > 0 OR INSTR(description, '平板') > 0看起来干净，但执行计划里它仍是全表扫描——每个INSTR都要逐行计算，且无法短路（即使第一个条件为真，第二个仍会执行）。而LIKE虽然也慢，但优化器对OR分支的预判有时更成熟。
真正有效的多关键字优化路径是：
- 如果关键词数量少且稳定（如就3个），优先建**全文索引**+
MATCH ... AGAINST('手机 平板')，这是MySQL原生支持的语义匹配 - 如果必须用函数，改用
REGEXP '手机|平板|电脑'，单次正则扫描比多次INSTR调用开销更低 - 若数据量超百万且QPS高，别在SQL层硬扛，把匹配逻辑下沉到应用层或引入Elasticsearch
INSTR参数顺序和返回值容易踩坑
MySQL的INSTR(str, substr)参数顺序是**被搜索字符串在前，目标子串在后**，和Java/Python的indexOf(substr, str)习惯相反。写成INSTR('张三', name)会永远返回0——因为MySQL把name当成了要搜索的源字符串，而字面量'张三'成了目标，逻辑完全颠倒。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
另外注意返回值含义：
-
INSTR('hello', 'x')→ 返回0（未找到） -
INSTR('hello', 'h')→ 返回1（从1开始计数，不是0） -
INSTR('', 'a')→ 返回0（空字符串中找不到任何子串） -
INSTR(NULL, 'a')→ 返回NULL，参与比较时需显式处理，如IFNULL(INSTR(field, 'x'), 0) > 0
想靠INSTR实现“精准词匹配”？它做不到
有人误以为INSTR(title, 'admin')能替代FIND_IN_SET('admin', title)，其实不能。INSTR只管连续字符是否存在，对'administrator'或'myadmin'也会返回非零值。它没有词边界概念。
如果你的字段存的是逗号分隔值（如'dev,admin,dba'），正确做法是：
- 用
FIND_IN_SET('admin', title)（仅限逗号分隔） - 或升级到MySQL 8.0+，用
JSON_CONTAINS(JSON_ARRAY_INSERT('[]', '$[0]', title), '"admin"')配合JSON化存储 - 最稳妥的是拆表——把多值关系转为关联表，用JOIN代替字符串解析
INSTR适合快速判断“有没有这段文字”，不适合判断“是不是一个独立的词”。后者涉及分词逻辑，数据库函数天生不擅长。
