INSTR在MySQL和Oracle中参数顺序相反且功能不同，MySQL仅支持2参数，Oracle支持4参数；PostgreSQL和SQL Server不支持INSTR，需改用POSITION或CHARINDEX；该函数无法利用索引，性能差，推荐用LIKE替代。
INSTR函数在MySQL和Oracle中用法差异大，别混用
INSTR不是SQL标准函数，MySQL和Oracle都支持但参数顺序相反，PostgreSQL和SQL Server根本不认这个函数名。直接照搬别人代码容易报错Unknown function 'INSTR'或返回错误位置。
MySQL里是INSTR(str, substr)，Oracle里是INSTR(str, substr, position, occurrence)，且默认从1开始计数（不是0）。比如INSTR('hello world', 'world')在MySQL返回7，在Oracle也返回7；但INSTR('abcabc', 'abc', 1, 2)在Oracle才返回4（第二次出现的位置），MySQL不支持后两个参数。
- MySQL只接受2个参数，多传会报语法错误
- Oracle若省略后两个参数，默认从第1位开始找第1次出现
- 返回值为0表示未找到（不是-1）
想在WHERE条件里判断子串存在？别只靠INSTR返回值
用INSTR(col, 'keyword') > 0能工作，但可读性差、索引利用率低。更直观且可能走索引的方式是用LIKE：col LIKE '%keyword%'。两者语义等价，但LIKE是SQL通用写法，维护成本更低。
如果必须用INSTR（比如要结合位置做后续计算），注意别写成INSTR(col, 'keyword') != 0——虽然结果对，但部分老版本MySQL优化器对!=识别不如>稳定。
- 避免
INSTR(col, 'a') = INSTR(col, 'b')这类逻辑，易引发隐式类型转换 - 当
col可能为NULL时，INSTR(NULL, 'x')返回NULL，整个条件变成UNKNOWN，行会被过滤掉 - 区分大小写取决于字段校对规则（collation），不是
INSTR本身控制
PostgreSQL或SQL Server用户：别搜INSTR，改用POSITION或CHARINDEX
硬套INSTR只会得到function instr does not exist。PostgreSQL用POSITION('substr' IN str)，SQL Server用CHARINDEX('substr', str)，两者都是从1开始、找不到返回0，行为接近MySQL的INSTR。
例如迁移MySQL语句SELECT * FROM t WHERE INSTR(name, 'admin') > 0到PostgreSQL，得改成WHERE POSITION('admin' IN name) > 0；SQL Server则是WHERE CHARINDEX('admin', name) > 0。
-
POSITION不支持指定起始位置，如需跳过前N位，得组合SUBSTRING -
CHARINDEX支持第三个参数：CHARINDEX('a', col, 5)从第5位开始找 - 所有这些函数对TEXT/LOB类型支持有限，超长字段可能截断或报错
性能敏感场景下，INSTR几乎无法利用索引
哪怕你在name字段建了B-tree索引，INSTR(name, 'abc') > 0依然大概率触发全表扫描。因为函数作用于列上，优化器无法下推索引范围查找。
真要查子串且要性能，优先考虑全文索引（MySQL FULLTEXT，PostgreSQL tsvector）或前置生成带索引的冗余字段（如has_admin BOOLEAN GENERATED ALWAYS AS (name LIKE '%admin%') STORED）。
- 用
INSTR做ORDER BY排序（如按首次出现位置）会导致filesort，数据量大时很慢 - 在JOIN条件里用
INSTR会让执行计划退化为嵌套循环，且无法使用索引加速关联 - 字符串越长，
INSTR计算开销越明显，尤其在SELECT列表中频繁调用
实际写查询时，先确认数据库类型，再选函数；别让一个INSTR把跨库兼容性和性能一起拖垮。
