MySQL 8.0前REGEXP不支持反向引用和懒惰匹配，提取需用SUBSTRING_INDEX+LOCATE或升级至8.0+用REGEXP_SUBSTR()；PG用~和regexp_matches()，后者支持捕获但返回数组；SQL正则无法替代应用层解析结构化数据。
MySQL 的 REGEXP 不支持反向引用和懒惰匹配
MySQL 原生 REGEXP（8.0 之前）用的是 Henry Spencer 的正则引擎，功能非常基础。它不支持 \1 这类捕获组反向引用，也不支持 *? 或 +? 这种懒惰量词——这意味着你没法靠正则直接提取“第一个引号对之间的内容”这种常见需求。
实操建议：
- 如果必须做分组提取（比如从
"name":"Alice"中取Alice），别硬扛，改用SUBSTRING_INDEX()+LOCATE()组合，或升级到 MySQL 8.0+ 用REGEXP_SUBSTR() - 避免写类似
\".*\"去匹配 JSON 字符串值——它会贪婪吞掉中间所有引号，直到最后一个"，结果错得离谱 - MySQL 5.7 及更早版本的
REGEXP区分大小写，但默认字符集（如utf8mb4_general_ci）会让比较实际不区分，行为容易误判，建议显式加BINARY控制
REGEXP_SUBSTR() 在 MySQL 8.0+ 怎么安全提取字段
MySQL 8.0 引入了 REGEXP_SUBSTR()，终于能做子串提取，但它默认只返回第一个匹配，且索引从 1 开始，和多数语言习惯相反。
实操建议：
- 提取 JSON key 的 value 时，用
REGEXP_SUBSTR(json_col, '"name"[[:space:]]*:[[:space:]]*"([^"]*)"', 1, 1, 'c', 1)—— 第 5 个参数'c'表示区分大小写，第 6 个参数1指定返回第 1 个捕获组 - 注意第 4 个参数是「第几次出现」，不是「从第几个字符开始」；想跳过前 N 次匹配，得手动算位置或嵌套调用
- 空匹配会返回
NULL，不是空字符串，做COALESCE(..., '')更稳妥 - 性能上，
REGEXP_SUBSTR()比纯字符串函数慢不少，高频查询字段建议提前解析并存到单独列
PostgreSQL 的 ~ 和 regexp_matches() 行为差异
PostgreSQL 不用 REGEXP 关键字，而是用操作符 ~（区分大小写）和函数 regexp_matches()。前者只返回布尔值，后者才真正提取——这点常被刚从 MySQL 切过来的人忽略。
实操建议：
-
WHERE col ~ '^\d{3}-\d{2}-\d{4}$'可以快速过滤社保号格式，但不能取其中段数字；要取，必须用regexp_matches(col, '(\d{3})-(\d{2})-(\d{4})', 'g') -
regexp_matches()默认只返回第一个匹配，加'g'标志才全量；但返回的是text[]数组，需配合UNNEST()或(...)[1]取值 - PostgreSQL 正则支持
(?i)内联标志，比在函数外加参数更灵活，比如col ~ '(?i)http://' - 若正则里有
$，注意它匹配行尾而非字符串尾——多行文本中可能意外失败，改用\Z
SQL 正则无法替代应用层解析的三个硬伤
无论 MySQL 还是 PostgreSQL，SQL 层正则都只是文本模式扫描工具，不是解析器。它没语法树、不理解嵌套结构、也无法处理转义逻辑。
典型踩坑场景：
- 解析 CSV 字段：含逗号的带引号字段（
"a,b",c,"d""e"）用正则基本不可靠，引号内转义、嵌套引号都会崩 - 提取 HTML 标签内容：哪怕简单如
<p>hello</p>，遇到<p onclick="alert('>')">test</p>就会错切，SQL 没状态机能力 - 验证邮箱或 URL：RFC 标准正则长达上千字符，SQL 执行慢且难以维护，不如应用层用成熟库（如 Python 的
email-validator）
真正需要结构化提取时，数据库该做的只是粗筛（比如 WHERE content REGEXP 'error|timeout'），精细解析留给应用代码——这不是偷懒，是边界清晰。
