MySQL 8.0+需用REGEXP_SUBSTR()提取子串，REGEXP仅返回0/1；其语法为REGEXP_SUBSTR(str,pattern[,pos[,occurrence[,match_type]]])，默认从位置1取第1次匹配，无匹配返回NULL。
REGEXP 在 MySQL 8.0+ 中如何匹配并提取子串
MySQL 原生 REGEXP（或 RLIKE）只做布尔判断，不返回匹配内容——想“提取”必须搭配 REGEXP_SUBSTR()。这个函数从 8.0.4 起才支持，低版本直接报错 FUNCTION REGEXP_SUBSTR does not exist。
常见误用是写成 SELECT column REGEXP 'pattern' 期望返回子串，结果只得到 0/1。真正提取得这样写：
SELECT REGEXP_SUBSTR('abc123def456', '[0-9]+') AS result;
返回 123（首个匹配）。注意它默认只取第一个，不自动全局遍历。
-
REGEXP_SUBSTR(str, pattern, pos, occurrence)：第四个参数occurrence控制取第几次匹配（如2取第二个数字串） - 省略
pos默认从位置 1 开始；occurrence=1是默认值，可不写 - 若无匹配，返回
NULL，不是空字符串——后续做CONCAT或COALESCE时得防空
嵌套查询中用 REGEXP_SUBSTR 提取多行不同模式
当需要对一列文本批量提取某种结构（比如日志里的 IP、URL 中的域名、JSON 片段里的 key），嵌套常用来先过滤再提取，或先提取再加工。关键点是：外层不能直接对未提取字段做 WHERE 条件，否则无法利用索引，且逻辑易错。
正确做法是把 REGEXP_SUBSTR() 放在子查询或 CTE 里计算出中间字段，再在外层筛选或连接：
SELECT ip_addr, COUNT(*)
FROM (
SELECT REGEXP_SUBSTR(log_line, '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}') AS ip_addr
FROM access_log
WHERE log_line REGEXP '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}'
) t
WHERE ip_addr IS NOT NULL
GROUP BY ip_addr;
- 内层
WHERE ... REGEXP先粗筛，减少REGEXP_SUBSTR计算量——正则引擎开销不小 - 外层再
WHERE ip_addr IS NOT NULL排除提取失败（如部分 IP 段超范围导致整个匹配失败） - 别在
WHERE里直接写REGEXP_SUBSTR(...) = '127.0.0.1'，MySQL 不会下推优化，可能全表扫描
嵌套 + REGEXP_SUBSTR 处理 JSON 或半结构化文本
面对类似 "user":"alice","score":85,"level":"gold" 这种伪 JSON 字符串，不用 JSON 函数（如 JSON_EXTRACT）而用正则，是因为字段名不固定、格式不严格，或 MySQL 版本低于 5.7。
这时嵌套常用来分步提取：先定位键，再抓值。例如提取 "score" 后的数字：
SELECT CAST(REGEXP_SUBSTR(payload, '"score"[^:]*:[^,}]*', 1, 1) AS CHAR) AS raw_pair,
REGEXP_SUBSTR(REGEXP_SUBSTR(payload, '"score"[^:]*:[^,}]*'), '[0-9]+') AS score_val
FROM events;
- 外层
REGEXP_SUBSTR先抓到"score":85整段，内层再从中抠数字——避免一次正则写太复杂难维护 -
[^,}]*比.*?更安全：防止跨字段匹配（比如"score":85,"level":"gold"中贪婪匹配会吞掉后面内容） - 如果值可能是字符串（如
"score":"N/A"），需改用'"score"[^:]*:[^,}]*'+ 更精细的二次提取，否则[0-9]+返回空
性能与兼容性陷阱
REGEXP_SUBSTR 在大表上跑嵌套查询很容易慢，尤其 pattern 写得宽泛（如 .* 开头）或 occurrence 设很大。线上查千万级日志表前，务必确认两点：是否真需要正则、有没有更稳的替代路径。
- MySQL 5.7/8.0 的
REGEXP引擎不支持反向引用（\1）、不支持 Unicode 属性类（如p{L}），写[a-zA-Z]更可靠 - PostgreSQL 用
REGEXP_MATCHES()或SUBSTRING()+ 正则，语法和行为差异大，别直接迁移 SQL - 如果字段有索引但用了
REGEXP_SUBSTR(col, ...)，索引完全失效——此时考虑生成列（generated column）加索引预计算
正则提取本质是字符串暴力扫描，嵌套只是组织方式；真正影响速度的是 pattern 复杂度和数据量级，不是“嵌套”本身。
