INSTR函数返回从1开始的位置索引，未找到返回0，行为因数据库而异且受排序规则影响大小写敏感性，使用时需注意空值处理、边界检查及版本兼容性。
INSTR函数返回的是从1开始的位置索引
多数人第一次用 INSTR 时会误以为它像 Python 的 str.find() 那样从 0 开始计数，结果发现匹配到第一个字符却返回 1，导致后续逻辑偏移。它在 MySQL、Oracle、PostgreSQL（通过兼容模式或 strpos 模拟）中行为一致：位置从 1 起算，没找到返回 0。
实操建议：
- 做字符串截取前，先判断
INSTR(col, 'keyword') > 0，而不是!= -1（那是 SQLite/Java 的习惯） - 若需转换为 0-based 偏移（比如配合
SUBSTRING计算起始点），显式减 1：SUBSTRING(col, INSTR(col, 'key') - 1, 2)，但注意INSTR返回 0 时减 1 会出错，得加CASE处理 - MySQL 8.0+ 支持四参数
INSTR(str, substr, pos, occurrence)，但多数旧版本只支持两参数或三参数（INSTR(str, substr, pos)），用前查文档
区分大小写取决于字段的 collation 或数据库配置
INSTR 本身不直接提供大小写开关参数，它的行为完全由字段的排序规则（collation）决定。例如 utf8mb4_unicode_ci 下 INSTR('Apple', 'apple') 返回 1；而 utf8mb4_bin 下返回 0。
实操建议：
- 不确定 collation 时，用
SHOW CREATE TABLE table_name查看字段定义 - 需要强制大小写敏感匹配，可临时转二进制：
INSTR(CAST(col AS BINARY), BINARY 'KeyWord')（MySQL） - Oracle 中可用
INSTRB处理字节级定位，但通常没必要，除非处理多字节字符且需精确字节偏移
替代方案：POSIX 正则更灵活，但性能差、语法重
当你要找“第 2 个逗号之后的第 3 个单词”，或者“匹配但排除注释行”，INSTR 就力不从心了。这时候有人想用 REGEXP_INSTR（MySQL 8.0+/Oracle），但它开销大、不可索引、跨库兼容性差。
实操建议：
- 简单子串定位，坚持用
INSTR—— 它能走索引（如果字段有前缀索引且查询是左前缀） - MySQL 中
REGEXP_INSTR(col, 'pattern', 1, 2)第 4 参数是 occurrence，但 pattern 编译成本高，10 万行以上表慎用 - PostgreSQL 没原生
INSTR，常用POSITION('x' IN col)（等价两参数INSTR）或STRPOS(col, 'x')，后者更常用且返回 0 表示未找到
嵌套使用 INSTR 提取中间片段容易漏边界检查
常见需求：“从 [start] 到 [end] 之间取内容”。直接写 SUBSTRING(col, INSTR(col,'[start]')+7, INSTR(col,'[end]')-INSTR(col,'[start]')-7) 看似简洁，但只要任一标签缺失，整个表达式就崩——INSTR 返回 0，导致负长度或越界。
实操建议：
- 必须用
CASE WHEN INSTR(col, '[start]') > 0 AND INSTR(col, '[end]') > INSTR(col, '[start]') THEN ... ELSE NULL END - MySQL 8.0+ 可用
REGEXP_SUBSTR替代，但同样要捕获失败场景，否则返回空字符串而非 NULL - 真正复杂的文本解析（如 JSON 片段、HTML 标签），别硬扛，导出到应用层用正则或专用解析器处理
实际用的时候，最常被忽略的是：INSTR 对 NULL 输入直接返回 NULL，而不是报错；所以字段可能为空时，外层一定要包一层 IFNULL 或 COALESCE，否则整条 CASE 或 SUBSTRING 就静默失效了。
