MySQL的REGEXP不支持反向引用和捕获组，仅返回0或1布尔值；8.0+新增REGEXP_SUBSTR()等函数才支持分组提取，且需注意POSIX ERE语法限制（如用[0-9]代替d）、无法走索引及性能开销问题。
MySQL的REGEXP不支持反向引用和捕获组
MySQL原生正则引擎（直到8.0仍基于Henry Spencer库）功能有限，REGEXP只能做匹配判断，不能提取子串或分组。如果你看到SELECT 'abc123' REGEXP '(\d+)' → 1，这仅表示“匹配成功”，但无法拿到123——想提取必须用SUBSTRING配合LOCATE或升级到8.0+用REGEXP_SUBSTR()。
常见误操作是照搬PCRE写法，比如'email@domain.com' REGEXP '([a-z]+)@([a-z]+)\.com'，语法上不报错，但结果仍是布尔值，且括号在这里只是字面量，不是分组。
- MySQL 5.7及更早：只支持
REGEXP/RLIKE，仅返回0或1 - MySQL 8.0+：新增
REGEXP_SUBSTR()、REGEXP_REPLACE()、REGEXP_INSTR()，才真正支持分组提取 - 避免在WHERE中对大字段高频使用
REGEXP，它无法利用索引，全表扫描开销明显
字符类和量词写法与标准正则有差异
MySQL的REGEXP默认使用POSIX ERE（扩展正则），不识别d、s、这类简写。例如'123abc' REGEXP '\d+'会失败，必须写成'123abc' REGEXP '[0-9]+'；'hello world' REGEXP '\s+'要改成'hello world' REGEXP '[[:space:]]+'。
另外，^和$锚点行为依赖上下文：在WHERE col REGEXP '^abc'中，^匹配字段开头；但在WHERE col REGEXP 'abc$'中，$并不严格匹配行尾，而是“abc后无更多非换行字符”，实际效果接近abc[[:space:]]*$。
-
[[:digit:]]、[[:alpha:]]、[[:punct:]]等POSIX字符类可用，比[0-9]更语义化 - 量词
+、*、{n,m}支持，但?（0或1次）需用{0,1}替代 - 如果需要大小写敏感匹配，加
BINARY前缀：BINARY col REGEXP '^ABC'
用REGEXP_REPLACE()在MySQL 8.0+安全清洗数据
MySQL 8.0引入的REGEXP_REPLACE()能真正做模式替换，比如清理电话号码中的非数字字符：REGEXP_REPLACE(phone, '[^0-9]', '')。注意它默认是贪婪匹配，且不支持/g标志——所有匹配都会被替换，无需额外指定全局模式。
一个典型陷阱是转义：函数第三个参数（替换字符串）中，\0代表整个匹配，\1、\2代表对应捕获组。但必须确保正则本身含括号分组，否则\1会被当作文本字面量处理。例如：REGEXP_REPLACE('2023-04-05', '^(\d{4})-(\d{2})-(\d{2})$', '\2/\1')返回'04/2023'。
- 若替换内容含反斜杠或美元符，需双写：
'\\'表示单个，'\$'表示字面量$ - 空替换（即删除）直接传空字符串
''，不要传NULL，否则整结果变NULL - 性能敏感场景慎用嵌套多层
REGEXP_REPLACE()，每次调用都重新编译正则
区分REGEXP和LIKE的适用边界
简单前缀/后缀模糊查用LIKE更快，因为可能走索引；涉及字符集范围、交替匹配、复杂位置逻辑时才上REGEXP。例如查“以a或e开头、后跟两个数字”的用户名：username REGEXP '^[ae][0-9]{2}'没法用LIKE表达，但username LIKE 'a%' OR username LIKE 'e%'又漏掉数字约束。
另一个关键区别是LIKE的_只匹配单字符、%匹配任意长度，而REGEXP可精确控制：'abcc' REGEXP 'ab.*c'匹配，但'abcc' LIKE 'ab%c'也匹配，二者语义不同——.*是正则的“任意字符零次或多次”，%是SQL通配符的“任意字符序列”。
-
LIKE 'abc%'可能命中索引，REGEXP '^abc'一定全表扫 -
REGEXP 'a.c'中.匹配任意单字符（包括换行符外的所有字符），LIKE 'a_c'中_只匹配单字符且不匹配NULL - 多条件组合时，
OR连多个LIKE有时比单个REGEXP更快，尤其当字段有前缀索引时
LEFT()/RIGHT()/INSTR()拆解？很多所谓“复杂匹配”，本质只是取子串或判断存在性——硬套正则反而增加维护成本和执行负担。 
