MySQL 8.0+ 正则仅支持ICU基础语法，不支持反向引用、命名捕获等PCRE特性，且REGEXP无法走索引，性能差；复杂场景应优先用函数组合、应用层处理或升级至8.0.30+使用REGEXP_SUBSTR。
MySQL 8.0+ 的 REGEXP 支持有限，别指望它能替代 PCRE
MySQL 原生 REGEXP（包括 REGEXP_LIKE）底层用的是 ICU 正则引擎，但只支持基础功能：字符类、量词、分组、锚点（^、$），不支持反向引用、命名捕获、条件断言、递归模式等。如果你写 REGEXP '(\d+)\.\1' 想匹配 123.123，会直接报错 ERROR 3685 (HY000): Invalid regular expression——因为 MySQL 不允许在正则中使用反向引用。
常见误操作：
- 把 Python 或 JavaScript 里跑通的正则原样粘进存储过程，结果语法报错或逻辑不匹配
- 试图用
REGEXP提取子串（比如从邮箱中取域名），但 MySQL 没有REGEXP_SUBSTR（直到 8.0.30 才加，且仅限部分模式） - 在 WHERE 中高频调用复杂
REGEXP，导致全表扫描无法走索引（即使字段有索引）
想真正做复杂匹配？得绕开 REGEXP，用函数组合或外部处理
MySQL 存储过程中没法动态加载正则库，也没法调用系统命令。可行路径只有三条：
-
拆解逻辑：把「匹配邮箱且域名长度 > 5」这种需求，改写成
LIKE '%@%.%'+CHAR_LENGTH(SUBSTRING_INDEX(email, '@', -1)) > 5 -
升级到 8.0.30+：可用
REGEXP_SUBSTR(str, pattern, pos, occurrence)提取，但注意occurrence参数从 1 开始，且不支持全局标志g，多次匹配得靠循环 - 前置清洗：在应用层（Python/Java）做完正则处理，只把结构化结果（如是否匹配、提取字段）传给存储过程做后续业务逻辑
示例：想从日志字段中提取 IPv4 地址（如 "src=192.168.1.1 port=80"）
SELECT REGEXP_SUBSTR(log_text, '\b(?:[0-9]{1,3}\.){3}[0-9]{1,3}\b', 1, 1) AS ip_addr
FROM logs;但这个正则在 MySQL 中实际会漏掉边界校验（ICU 对 \b 支持不稳定），更稳妥的是用四段 SUBSTRING_INDEX + CAST 校验数字范围。
PostgreSQL 用户请直接用 ~ 和 substring()，别纠结 MySQL 那套
如果你其实用的是 PostgreSQL（常被误认为“支持正则的 SQL”），那体验完全不同：~ 操作符默认就是 POSIX ERE，支持 +、?、|、分组捕获；substring(str FROM pattern) 能直接取捕获组；还有 regexp_replace() 和 regexp_split_to_table() 等完整工具链。
例如提取 URL 中的 host：
SELECT substring('https://api.example.com/v1' FROM 'https?://([^/]+)'); -- 返回 'api.example.com'而 MySQL 同样需求得写三层嵌套 SUBSTRING_INDEX，还容易因协议缺省（//example.com）出错。
存储过程里写正则？先问自己：是不是真需要在数据库层做
正则匹配是 CPU 密集型操作，放在存储过程中会让数据库承担本该由应用层处理的文本解析职责。尤其当：
- 输入数据格式多变（JSON/XML/日志混杂），需不同正则规则
- 要返回多个匹配结果（MySQL 不支持
REGEXP全局匹配数组） - 涉及 Unicode 处理（如中文姓名校验），MySQL 的 collation 和正则引擎对 UTF8MB4 支持仍有边界 case
真正关键的不是「能不能写」，而是「值不值得写」——多数情况下，把 REGEXP 逻辑提到应用层，存储过程只接收清洗后的字段，性能和可维护性反而更好。
