直接用substr配instr常截错位置，因instr返回起始偏移（从1开始），而substr第二参数是起始位置、第三参数是长度；常见错误是误将instr结果当长度用，或未跳过分隔符本身（如取下划线间内容时未+1）、未正确计算长度（应为右边界−左边界−1），且忽略空值、单分隔符、大小写等边界情况。
为什么直接用 SUBSTR 配 INSTR 常截错位置？
因为 INSTR 返回的是起始偏移（从1开始），而 SUBSTR 的第二个参数是起始位置，第三个参数是长度——但很多人误把 INSTR 的结果当“长度”用，或混淆了前后分隔符的查找顺序。
典型错误：想取两个下划线 _ 之间的内容，却写成 SUBSTR(str, INSTR(str, '_'), INSTR(str, '_', INSTR(str, '_')+1) - INSTR(str, '_'))，结果开头多了一个 _，长度还少1。
-
INSTR(str, '_')找到第一个_的位置，比如是5 → 起始点应为5 + 1才能跳过它 - 第二个
INSTR要从5 + 1开始搜，否则会重复命中同一个_ - 长度 = 第二个位置 − 第一个位置 − 1（不是减2，也不是不减）
Oracle/MySQL 8.0+ 中安全提取「第n个分隔符后、第m个分隔符前」的文本
场景：字段值为 'user_20240521_v2_report.csv'，需提取中间的日期部分 '20240521' —— 它位于第1个和第2个 _ 之间。
关键逻辑：用两次 INSTR 分别定位左右边界，再用 SUBSTR 截取。注意不同数据库对 INSTR 参数的支持差异：
- Oracle：
INSTR(str, substr, [start_pos], [occurrence])支持第4个参数指定第几次出现 - MySQL 8.0+：同样支持第4个参数；老版本需嵌套
INSTR - PostgreSQL 不支持
INSTR，得换POSITION+SUBSTRING或正则
Oracle 示例（取第1个与第2个 _ 之间）：
SUBSTR( col_name, INSTR(col_name, '_', 1, 1) + 1, INSTR(col_name, '_', 1, 2) - INSTR(col_name, '_', 1, 1) - 1 )
若字段可能不含两个 _，该表达式会报错（如 INSTR 返回0，导致负长度）。必须加 CASE 判断：
CASE WHEN INSTR(col_name, '_', 1, 2) > 0 THEN SUBSTR(...同上...) ELSE NULL END
处理末尾无分隔符或空字段时的隐性崩溃点
常见现象：SQL执行不报错，但结果为空或截出意外字符，尤其在 GROUP BY 或 JOIN 后字段被隐式截断。
- 空字符串或
NULL输入时，INSTR返回0 →SUBSTR(str, 0, ...)在 Oracle 中等价于SUBSTR(str, 1, ...)，但在某些驱动里行为不一致 - 目标分隔符只出现1次，但代码按2次找 →
INSTR(..., 2)返回0 → 长度算成负数 → 多数数据库返回空字符串，但不易察觉 - 区分大小写：默认
INSTR区分大小写，若源数据含混合大小写分隔符（如'User_ID'和'user_id'），需先统一转小写
防御写法（Oracle）：
SUBSTR(
col_name,
NULLIF(INSTR(LOWER(col_name), '_'), 0) + 1,
NULLIF(INSTR(LOWER(col_name), '_', 1, 2), 0)
- NULLIF(INSTR(LOWER(col_name), '_'), 0)
- 1
)
比 SUBSTR+INSTR 更稳的替代方案
当逻辑变复杂（比如要取第3个 - 和第4个 . 之间），嵌套 INSTR 可读性急剧下降，且难以调试。
- Oracle 推荐用
REGEXP_SUBSTR：例如REGEXP_SUBSTR(col_name, '_([^_]*)_([^_]*)', 1, 1, NULL, 1)直接捕获第一个下划线后的非下划线段 - MySQL 8.0+ 可用
REGEXP_SUBSTR，语法类似 - 如果仅需简单分割，且数据库支持，
STRING_SPLIT（SQL Server）或split_part（PostgreSQL）更直观
但要注意：正则性能通常低于原生字符串函数，高频查询中需权衡。真正卡住你的，往往不是函数不会用，而是没验证边界输入是否全量覆盖。
