MySQL正则能力严重依赖版本：5.7及以前仅支持转义的POSIX BRE，8.0+启用ICU引擎支持d、p{Han}等但不支持断言和反向引用；REGEXP_SUBSTR()仅8.0+可用且捕获组受限；性能差、难索引，复杂场景应交由应用层处理。
MySQL 的 REGEXP 能应付多数模式筛选，但“复杂”二字要拆开看：8.0+ 可做基础捕获和替换，5.7 及更早版本连 + 和 ? 都得双反斜杠转义，且完全不支持分组捕获、断言、Unicode 属性等。别指望它替代应用层正则。
确认 MySQL 版本与正则引擎能力
执行 SELECT VERSION(); 是第一步。若返回 5.7.34 或更低，说明你用的是 POSIX BRE 引擎——[[:digit:]] 可用，但 d 会报错；+ 必须写成 +；{2,5} 得写成 {2,5}。8.0+ 默认启用 ICU 引擎，支持 d、s、(?i)、p{Han} 等，但依然不支持 (?=...) 或 K。
- 查当前正则是否启用 ICU：
SELECT @@collation_server;若含0900（如utf8mb4_0900_as_cs），大概率已就绪 - 5.7 中强行用
d会静默失败（匹配永远为 false），不是语法错误，容易误判 - ICU 不等于 PCRE：像
(a)(b)这类反向引用在 MySQL 里始终不支持
提取子串必须用 REGEXP_SUBSTR()，但注意捕获组限制
想从 '订单号：ORD-2024-00123' 里取 '2024-00123'？8.0+ 可用 REGEXP_SUBSTR(order_id, 'ORD-([0-9]{4}-[0-9]{5})', 1, 1, '', 1)，其中末尾的 1 表示取第一个捕获组。但这里有几个硬约束：
- 第 6 个参数才是
subexpr（捕获组编号），顺序不能错；漏掉或填错会返回整个匹配，而非括号内容 - 不支持命名捕获组，只能靠数字索引，嵌套括号时极易数错
- 只返回第一个匹配结果，无法批量提取多个同类子串
- 5.7 完全没有这个函数，只能靠
SUBSTRING_INDEX()+LOCATE()拼凑，可靠性差
区分大小写、中文匹配与常见陷阱
REGEXP 'abc' 默认不区分大小写，但 REGEXP BINARY 'abc' 或字段 COLLATE utf8mb4_bin 才真区分。中文匹配更易踩坑：
- 用
[u4e00-u9fa5]前必须双反斜杠：name REGEXP '[\u4e00-\u9fa5]'，否则 MySQL 当普通字符处理 - 更可靠写法是
name REGEXP '\p{Han}'（仅 8.0+ ICU），能覆盖扩展汉字（如「?」「?」） - 字段字符集必须是
utf8mb4，utf8（即 utf8mb3）会截断四字节 Unicode，导致匹配失败 -
NOT REGEXP不是简单取反：若字段为 NULL，结果也是 NULL，不是 true —— 条件中需额外加IS NOT NULL
性能问题比语法更致命
REGEXP 查询几乎无法走索引，哪怕你在字段上建了 B-tree 索引。执行 EXPLAIN 会看到 type: ALL，意味着全表扫描。尤其当表有百万行、又带 OR 分支（如 'abc|def|xyz'）时，响应可能从毫秒级跳到秒级。
- 能用
LIKE 'prefix%'就别用REGEXP '^prefix'，前者可走前缀索引 - 把正则逻辑前置：比如用触发器/应用层预计算字段（如加
is_mobile布尔列），再用普通条件查询 - 全文索引（
MATCH ... AGAINST）对自然语言搜索更高效，别硬塞正则进去 - 真正复杂的文本解析（如日志结构化、HTML 提取），应该交给 Python/Go 等语言处理，MySQL 只存清洗后结果
正则在 MySQL 里是个“够用但别太信”的工具。最常被忽略的其实是版本差异带来的行为断裂——同一句 REGEXP 'd+'，在 5.7 里查不到任何数据，在 8.0 里却能跑通。上线前务必在目标环境实测，而不是照着文档抄。
