INSTR函数跨数据库兼容性差：MySQL/Oracle用INSTR(str,substr)，PostgreSQL用POSITION(substr IN str)或STRPOS，SQL Server用CHARINDEX(substr,str)；返回值从1开始且查无返回0，空串处理需谨慎，性能不如LIKE等原生匹配。
INSTR 函数在不同数据库里名字不一样
MySQL 和 Oracle 支持 INSTR，但 PostgreSQL 用的是 POSITION，SQL Server 则得靠 CHARINDEX。直接写 INSTR 在 PostgreSQL 或 SQL Server 里会报错：function instr does not exist 或 Invalid column name 'INSTR'。
如果你正在迁移 SQL 脚本或写跨库兼容代码，别硬套名字——先看当前数据库支持哪个函数：
- MySQL / Oracle：
INSTR(str, substr)（参数顺序是「被查字符串、子串」） - PostgreSQL：
POSITION(substr IN str)或STRPOS(str, substr) - SQL Server：
CHARINDEX(substr, str)（注意：参数顺序和 MySQL 相反）
MySQL 的 INSTR 返回位置从 1 开始，不是 0
这和大多数编程语言的 indexOf 不同。比如 INSTR('hello world', 'w') 返回 7，不是 6；查不到时返回 0，不是 -1。这个偏移习惯容易在条件判断里埋坑。
常见误用场景：
- 写成
WHERE INSTR(col, 'abc') > -1—— 实际应为> 0 - 用结果直接做数组下标（比如传给
SUBSTRING）却忘了加/减 1，导致截取错位 - 和
LOCATE混用：MySQL 中LOCATE参数顺序可选，INSTR固定，别把两个当一回事
用 INSTR 做模糊前缀判断要小心空字符串
INSTR('abc', '') 在 MySQL 中返回 1，Oracle 返回 1，但行为不具业务意义——空字符串总“出现在开头”。如果代码逻辑是“检查是否以某字符串开头”，别依赖 INSTR 结果是否等于 1，而该用 LIKE 'prefix%' 或 LEFT(col, n) = 'prefix'。
更稳妥的前缀判断写法：
- MySQL：
INSTR(col, 'abc') = 1可用，但需确保右边不是空串（加AND 'abc' != ''） - 想兼容所有情况，优先走
col LIKE 'abc%'，语义清晰且能用索引 - 若必须用函数，PostgreSQL 推荐
STARTS_WITH(col, 'abc')，SQL Server 用LEFT(col, 3) = 'abc'
INSTR 性能不如原生模式匹配，别在 WHERE 条件里滥用
INSTR 是函数调用，对字段使用会阻止索引走范围扫描（除非有函数索引，如 MySQL 8.0+ 的函数索引或 PostgreSQL 的表达式索引）。比如 WHERE INSTR(title, 'error') > 0 通常触发全表扫描。
替代方案按场景选：
- 查固定前缀：
title LIKE 'Error%'—— 可走 B-tree 索引 - 查固定后缀：
title LIKE '%log'—— 大部分引擎无法索引，考虑倒序存储 + 前缀查询，或用全文索引 - 查任意位置子串且数据量大：上
FULLTEXT（MySQL）或tsvector（PostgreSQL），别硬扛INSTR
真正需要 INSTR 的地方，通常是字符串解析类逻辑（比如拆分路径、提取域名、定位分隔符），而不是做搜索过滤。
