MySQL的REGEXP和RLIKE能用但功能受限：不支持捕获组、反向引用、懒惰匹配、\d等简写，大小写由collation决定；8.0+新增函数仍无完整替换能力，性能差且无法走索引。
MySQL的REGEXP和RLIKE到底能不能用？
能，但别指望它像PCRE或JavaScript那样灵活。MySQL原生正则引擎（截至8.0）基于Henry Spencer的正则库，不支持捕获组、反向引用、懒惰匹配、\d等简写字符类（得写[0-9]），也不支持g或i标志位——大小写敏感性由列的collation决定。
实际使用时，优先确认你的MySQL版本：SELECT VERSION();。5.7及以下功能更受限；8.0起引入了REGEXP_LIKE()、REGEXP_SUBSTR()等函数，但依然不支持替换操作（没有REGEXP_REPLACE()的完整语义，8.0.4+才有该函数，且仅支持基本替换，无回调或分组引用）。
怎么写一个靠谱的邮箱格式校验？
别用网上抄来的“万能正则”，MySQL里连+量词都得转义成\+（在字符串字面量中还要再加一层反斜杠），稍不注意就变成字面匹配。真实可用的邮箱基础校验长这样：
SELECT * FROM users
WHERE email REGEXP '^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}$';注意点：
-
^和$必须显式写出，MySQL不会自动锚定到字符串首尾 -
+是特殊字符，要匹配字面加号得写\+；但在字符组[...]里不用转义（如[+-]合法） -
{2,}可用，但{2,5}在旧版本可能不支持，建议用{2,99}兜底 - 如果列是
utf8mb4_unicode_cicollation，REGEXP默认不区分大小写；想强制区分，改用REGEXP BINARY
REGEXP_SUBSTR()提取内容时为什么总返回NULL？
常见原因是：没匹配上、索引参数错、或MySQL版本太低（REGEXP_SUBSTR()仅8.0.4+支持）。它不像SUBSTRING_INDEX()那么宽容——只要模式不完全命中，就返回NULL。
比如想从日志字段log_text中提取error_code=123里的数字：
SELECT REGEXP_SUBSTR(log_text, 'error_code=([0-9]+)', 1, 1, 'c', 1) AS code FROM logs;
关键参数说明：
- 第3个参数
1：起始位置（从1开始） - 第4个参数
1：匹配第几次出现（不是子组编号） - 第5个参数
'c'：匹配模式，c=case-sensitive，i=insensitive - 第6个参数
1：返回第1个捕获组的内容（即括号里的[0-9]+）；若为0，则返回整个匹配串
容易漏掉的是：如果没写第6个参数，默认返回整个匹配（不是第1组），而且如果正则本身没带括号，第6个参数设为1会直接报错。
性能差得离谱？那是你没避开这些坑
正则在MySQL里无法走索引（哪怕前缀匹配也不行），全表扫描是常态。线上表超过10万行，WHERE col REGEXP '...'基本等于慢查询定时炸弹。
可行的优化路径：
- 把需要高频正则匹配的字段，额外存一个标准化标识字段（如
is_email_valid TINYINT），用触发器或应用层维护 - 用
LIKE前置固定字符串代替部分正则，例如WHERE phone LIKE '13[0-9]%' AND phone REGEXP '^13[0-9]{9}$'，先用LIKE快速过滤 - 复杂文本分析坚决移出MySQL，交给Elasticsearch或应用层的Python/Java正则处理
- 避免在
ORDER BY或GROUP BY里嵌套REGEXP_SUBSTR()，计算开销翻倍
最常被忽略的一点：MySQL正则不支持Unicode属性类（如\p{L}），处理中文、emoji时，得靠utf8mb4 collation + 字符范围硬写，比如[\x{4e00}-\x{9fff}]在MySQL里根本不能用——只能退化成[\u4e00-\u9fff]，且依赖客户端连接编码正确设置。
