INSTR在MySQL中返回子串在主串中首次出现的起始位置（从1开始），首参为主串、次参为子串，未找到返回0；不区分大小写，支持多字节字符，但不支持直接指定第n次匹配。
MySQL里用INSTR找字符位置，但注意参数顺序和返回值含义
INSTR在MySQL中是「子串在主串中的起始位置」，从1开始计数，不是0。第一个参数是主字符串，第二个才是要查找的子串——这点和很多编程语言的indexOf相反，容易写反。
常见错误现象：把参数顺序颠倒，比如写成 INSTR('a', 'abc')，结果永远是0（找不到），实际该写成 INSTR('abc', 'a') 返回1。
- 如果子串不存在，
INSTR返回0，不是NULL - 支持多字节字符（如中文），但不区分大小写（除非字段是binary或使用
BINARY修饰） - 想查第二次出现的位置？得嵌套用，比如
INSTR(SUBSTRING(str, INSTR(str, 'x') + 1), 'x') + INSTR(str, 'x')，很绕，建议改用正则或程序层处理
SQL Server必须用CHARINDEX，它和INSTR行为相似但参数顺序一致
CHARINDEX的参数顺序是「要找的子串、主串、起始位置（可选）」，前两个刚好和INSTR反过来。这意味着跨数据库迁移SQL时，光替换函数名不够，还得调换参数。
使用场景：比如提取邮箱@符号前的用户名，SUBSTRING(email, 1, CHARINDEX('@', email) - 1)。但如果email里没有@，CHARINDEX返回0，SUBSTRING就会报错「长度不能为负」。
- 安全写法要加
CASE WHEN CHARINDEX('@', email) > 0 THEN ... ELSE NULL END - 第三个参数指定起始搜索位置，可用于跳过首次匹配，例如找第二次出现的逗号：
CHARINDEX(',', str, CHARINDEX(',', str) + 1) -
CHARINDEX区分大小写与否，取决于列的排序规则（collation），不是函数本身控制
PostgreSQL没有INSTR或CHARINDEX，得用POSITION或STRPOS
PostgreSQL用POSITION('x' IN str)，语法更接近自然语言，且返回值也是从1开始。但它不支持指定起始偏移，也没办法直接找第n次出现——这是硬限制。
替代方案：STRPOS(str, 'x')功能相同，但更常用；若需复杂定位（如找倒数第二次出现），只能结合REGEXP_REPLACE或数组函数（如string_to_array）拆解处理。
-
POSITION和STRPOS对空字符串''都返回1，不是0或NULL，这点和MySQL/SQL Server都不一样 - 正则方式虽然灵活，但性能明显下降，尤其在大字段或无索引列上慎用
- 如果只是判断存在性，用
str LIKE '%x%'比POSITION更直观，也更容易被优化器利用索引
跨数据库兼容写法几乎不存在，别试图封装成统一函数
有人想写个视图或UDF来统一接口，比如叫FIND_POS(str, sub)，但各数据库对NULL处理、空串行为、大小写敏感逻辑全都不一致。强行封装只会掩盖问题，让调试更困难。
真正可行的做法是：在应用层做适配，或者在SQL模板里用条件宏（如MyBatis的<if test="database == 'mysql'"></if>）生成对应函数调用。
- 别依赖返回值是否为NULL来判断失败——MySQL返回0，SQL Server返回0，PostgreSQL返回1（对空串），语义根本不统一
- 涉及计算切片位置时（如
SUBSTRING），务必先校验查找结果是否有效，否则线上可能突然报错 - 如果业务逻辑重度依赖字符位置，优先考虑在应用代码里用
indexOf/find等原生方法处理，SQL只负责原始数据获取
