INSTR函数返回子串首次出现的起始位置（整数，从1开始计数），未找到返回0；非布尔值，不可直接用于WHERE条件，须显式判断>0；参数顺序为INSTR(源串,子串)，Oracle支持起始位置和第几次出现，MySQL仅前两参数或三参数，PostgreSQL用POSITION，SQL Server用CHARINDEX。
INSTR 函数返回的是位置，不是布尔值
SQL 中的 INSTR（MySQL、Oracle、SQLite 支持；PostgreSQL 用 POSITION，SQL Server 用 CHARINDEX）本质是查找子串首次出现的起始位置，**返回整数**，不是 true/false。直接拿它当条件判断容易出错——比如查字符 'a' 在 'apple' 中是否存在，INSTR('apple', 'a') 返回 1，但如果你写 WHERE INSTR(col, 'a')，在 MySQL 中会隐式转成布尔（非零为真），可一旦查的子串在开头，返回 1 没问题；若子串在第 0 位？等等——INSTR **从 1 开始计数，永远不会返回 0**；找不到才返回 0。
- ✅ 正确写法是显式比较：
INSTR(col, 'x') > 0 - ❌ 错误写法：
INSTR(col, 'x')（依赖隐式转换，语义模糊，SQL Server 不支持这种用法） - ⚠️ 注意：Oracle 的
INSTR默认从位置 1 开始，但支持第 3 参数指定起始偏移，负数表示从末尾倒查，别漏掉参数顺序
MySQL 中判断字符存在性的典型写法
在 MySQL 里最常用场景是过滤含某个字符的记录，比如查用户名包含下划线的用户：
SELECT * FROM users WHERE INSTR(username, '_') > 0;
等价但更直观的写法其实是 LIKE：username LIKE '%_%'，但 INSTR 优势在于能进一步做逻辑延伸——比如只找第二个下划线之后的内容，这时就得靠 INSTR(col, '_', 1, 2)（MySQL 8.0+ 支持第 4 参数表示第几次出现）。
-
INSTR(str, substr)：基础两参数，返回首次位置 -
INSTR(str, substr, pos)：从pos位置开始找（MySQL 支持，Oracle 也支持，但 Oracle 的pos可为负） - 性能上，
INSTR和LIKE在无索引时都是全表扫描，别指望它走索引——除非你建了函数索引（MySQL 8.0+ 支持对表达式建索引）
跨数据库兼容性陷阱
想写一次 SQL 跑多个库？INSTR 是重灾区。PostgreSQL 根本没有 INSTR，得用 POSITION('x' IN col)，返回同样是整数，也需写成 POSITION('x' IN col) > 0；SQL Server 必须用 CHARINDEX('x', col)，且参数顺序是 (substr, str)，和 MySQL 相反。
- MySQL / SQLite：
INSTR(str, substr) - PostgreSQL：
POSITION(substr IN str)或STRPOS(str, substr) - SQL Server：
CHARINDEX(substr, str) - Oracle：
INSTR(str, substr [, start_position [, occurrence]])，默认start_position = 1，occurrence = 1
容易被忽略的空值和大小写问题
INSTR 遇到 NULL 输入一律返回 NULL，而 NULL > 0 结果还是 NULL，在 WHERE 子句中相当于不匹配——这常导致数据“消失”，尤其当字段允许为空时。
- 务必加
col IS NOT NULL判断，或用COALESCE(INSTR(col, 'x'), 0) > 0 - 所有主流数据库中，
INSTR默认区分大小写（MySQL 在 utf8mb4_bin 排序规则下严格区分；若用 _ci 规则则不区分），别假设它自动忽略大小写 - 想实现不区分大小写的查找，得先统一转大小写：
INSTR(UPPER(col), UPPER('x')) > 0
实际用的时候，先确认你的数据库类型，再核对参数顺序和空值行为——尤其是把测试语句从开发环境搬到生产时，Oracle 和 MySQL 看似一样，但第 3 参数含义可能差一个符号。
