REGEXP_SUBSTR可提取CSV第N字段，但Oracle与MySQL行为不同：Oracle用occurrence参数直接指定序号，MySQL需显式传position和occurrence；正则应避开连续分隔符和嵌套逗号，含引号或括号时须锚定边界并注意捕获组支持差异。
REGEXP_SUBSTR提取固定分隔符后的字段（如CSV片段）
直接用 REGEXP_SUBSTR 提取第 N 个以逗号分隔的值，关键在正则模式和位置参数配合。Oracle 和 MySQL 8.0+ 支持该函数，但行为有差异：Oracle 默认从第 1 位开始匹配，MySQL 默认从第 1 个字符起搜索，且不支持 occurrence 参数（需靠 pos 和 occurrence 模拟）。
常见错误是写成 REGEXP_SUBSTR(str, '[^,]+', 1, 2) 却没考虑开头空格或连续逗号——这会导致第 2 段取到空字符串或错位。
- Oracle 示例：提取 "a,b,c,d" 中第 3 个字段 →
REGEXP_SUBSTR('a,b,c,d', '[^,]+', 1, 3)返回c - MySQL 8.0+ 需显式指定起始位置和出现次数：
REGEXP_SUBSTR('a,b,c,d', '[^,]+', 1, 3, 'c')（'c'表示区分大小写，可省略） - 若字段含逗号（如 CSV 中带引号的字段），
[^,]+会断裂；此时应先用REGEXP_REPLACE清洗或改用更健壮的解析逻辑
用REGEXP_SUBSTR匹配带括号或引号的结构化内容
提取形如 name="John" 或 id(123) 这类带边界符号的内容，正则必须锚定分隔符，否则容易跨段匹配。
典型陷阱是写 REGEXP_SUBSTR(str, '"[^"]*") 却漏掉开头的 " ——实际应写成 REGEXP_SUBSTR(str, '"([^"]*)"', 1, 1, NULL, 1)（Oracle 支持第 6 参数提取捕获组），MySQL 不支持捕获组提取，得靠嵌套 REGEXP_SUBSTR + SUBSTRING_INDEX 组合。
- Oracle 提取双引号内内容（不含引号）：
REGEXP_SUBSTR(str, '"([^"]*)"', 1, 1, NULL, 1) - MySQL 8.0+ 只能取整个匹配：
REGEXP_SUBSTR(str, '"[^"]*"')，再用TRIM(BOTH '"' FROM ...)去引号 - 括号内容同理：
REGEXP_SUBSTR(str, '\(([^)]*)\)', 1, 1, NULL, 1)（注意反斜杠转义）
REGEXP_SUBSTR性能差？别在WHERE里反复调用
在 WHERE 条件中对大表字段多次调用 REGEXP_SUBSTR，几乎必然触发全表扫描，尤其当正则含 .* 或未锚定开头时，数据库无法利用索引。
真正影响性能的是正则复杂度和数据量级。一个 REGEXP_SUBSTR(col, 'status:([a-z]+)') 在百万行表上可能比等值查询慢 10–50 倍。
- 优先考虑是否能用
SUBSTR+INSTR替代（如已知格式固定） - 若必须用正则，把提取结果作为生成列（MySQL 5.7+ / Oracle 12c+）并建索引
- 避免在 JOIN 条件或子查询外层反复调用；提取逻辑尽量下推到子查询内，减少中间结果集大小
不同数据库对REGEXP_SUBSTR的支持差异
PostgreSQL 没有 REGEXP_SUBSTR，得用 substring(str FROM 'pattern') 或 (regexp_matches(str, 'pattern'))[1]；SQL Server 完全不支持原生正则提取，得靠 STRING_SPLIT + CHARINDEX 拼凑。
最易被忽略的是空匹配行为：Oracle 对空字符串返回 NULL，MySQL 返回空字符串，而某些版本在 occurrence 超出范围时静默返回 NULL —— 这会让业务逻辑误判为“字段不存在”而非“无匹配”。
- Oracle：
REGEXP_SUBSTR('abc', 'd')→NULL - MySQL：
REGEXP_SUBSTR('abc', 'd')→NULL（注意：MySQL 8.0.22+ 才稳定支持此行为，旧版可能报错） - 测试前务必确认数据库版本，特别是
occurrence参数是否被忽略（如早期 MySQL 版本会无视该参数）
