instr() 替代 LIKE '%xxx%' 可提速30%–50%，但必须配合函数索引且谓词严格写为 instr(col,'xxx')>0，否则无效；参数顺序、负值逻辑及中文需用 instrb() 等细节影响正确性与性能。
直接用 instr() 替代 LIKE '%xxx%'，能显著提速，尤其在百万级以上数据量时——但必须配合函数索引，否则只是白换。
为什么 instr() 比 LIKE 快
根本区别在于执行路径：LIKE '%xxx%' 无法走普通 B-Tree 索引（% 开头强制全表扫描），而 instr(col, 'xxx') > 0 是确定性函数调用，可创建函数索引加速。
- 测试数据量 100 万行时，
instr()查询比LIKE快 30%–50% - 若已为
instr(col, 'xxx')建好函数索引，1000 万行场景下速度可达instr()无索引版的 10 倍以上 -
instr()返回的是位置数值，数据库优化器更容易估算选择率，生成更优执行计划
怎么写才真正生效：函数索引 + 正确谓词
只改 WHERE 条件不建索引，等于没优化；建了索引但写法不对，索引也用不上。
- 必须用
instr(col, 'xxx') > 0—— 这个表达式才能命中你为instr(col, 'xxx')创建的函数索引 - 不能写成
instr(col, 'xxx') != 0或instr(col, 'xxx') >= 1，部分 Oracle 版本可能无法识别索引使用条件 - 函数索引语句示例：
CREATE INDEX idx_emp_name_java ON employees (instr(job_title, 'Java')); - 对应查询必须严格匹配：
SELECT * FROM employees WHERE instr(job_title, 'Java') > 0;
instr() 参数陷阱与常见误用
参数顺序和取值逻辑容易出错，导致结果不符或索引失效。
-
start_position为负数时，是从右往左找，但返回的位置仍是**从左起的正向序号**（例如instr('abcde', 'e', -1)返回 5，不是 1） -
nth_appearance不能为负数，否则报 ORA-01428 错误 - 省略
start_position默认从 1 开始，但如果你建的是instr(col, 'xxx', 1)的索引，就不能在查询里写成instr(col, 'xxx')（少参数），Oracle 视为不同函数，索引不可用 - 中文等双字节字符建议用
instrb()配合字节偏移逻辑，避免截断风险
什么情况下别硬上 instr()
不是所有模糊场景都适合它。盲目替换反而引入维护负担。
- 要查的关键词不固定（比如用户自由输入搜索），没法提前为每个关键词建函数索引 → 改用
CONTAINS+ 全文索引 - 需要支持正则复杂匹配（如邮箱校验、分隔符提取）→
REGEXP_LIKE更合适，尽管它比instr()慢约 60% - 字段本身已有前缀索引且查询多为
LIKE 'xxx%'→ 直接走原索引更轻量，无需函数索引 - 表更新极频繁，函数索引会拖慢 DML 性能 → 需权衡读写比例
真正关键的不是函数本身，而是你是否把 instr(col, 'xxx') 当作一个可索引的“计算列”来设计——建索引、写谓词、压参数，三者缺一不可。漏掉任意一环，性能就打回原形。
