是的，regexp和rlike在mysql中完全等价，底层调用同一正则引擎，返回1（匹配成功）或0（失败），null参与运算时结果为null；二者可互换使用，但regexp更贴近sql标准、可读性略强。
REGEXP 和 RLIKE 真的等价吗？
是的，REGEXP 和 RLIKE 在 MySQL 中完全等价，底层实现相同，返回值也一样：匹配成功返回 1，失败返回 0，任一操作数为 NULL 则结果为 NULL。你可以混用，但建议统一用 REGEXP，因为它是 SQL 标准更接近的写法，可读性略强。
注意：NOT REGEXP 是合法语法，但 ! REGEXP 无效；同样，NOT RLIKE 可用，! RLIKE 会报错。
^ $ . * + 这些元字符怎么用才不踩坑？
MySQL 的正则引擎基于 POSIX ERE（扩展正则表达式），不支持 PCRE 中的 d、s、?、 等，也不支持非贪婪匹配。常见误用点：
-
^和$是“锚点”，不是字面字符——name REGEXP '^张'匹配以“张”开头的姓名，但name REGEXP '^张'会去匹配字面的^张字符串（几乎不会命中） -
.匹配任意单个字符（包括空格、制表符），不是“任意长度”——想匹配“张三”或“张小三”，不能写'^张.*三$'，而应写'^张.*三$'（.*才表示任意字符任意次数） -
*必须跟在某个原子后才有意义，单独写'*'会报错；'a*'表示“a 出现 0 次或多次”，'a+'表示“a 至少出现 1 次” - 重复量词
{n}或{n,m}只能用于前一个字符或分组，且必须用括号包裹复杂结构，例如'([0-9]){3}'匹配连续 3 个数字，但'[0-9]{3}'同样有效（无需括号）
为什么 WHERE name REGEXP 'admin' 比 LIKE '%admin%' 更危险？
表面看两者都找含 “admin” 的记录，但行为本质不同：
-
LIKE '%admin%'是索引友好型模糊查询（如果字段有前缀索引且 pattern 不以 % 开头，仍可能走索引） -
name REGEXP 'admin'**必然触发全表扫描**——MySQL 无法为正则表达式建立有效索引，即使该列有 B-tree 索引也无用 - 更隐蔽的风险：
REGEXP默认大小写不敏感（取决于列 collation），而LIKE行为与 collation 强绑定；若你依赖大小写区分（如查'Admin'而非'admin'），必须显式加BINARY：name REGEXP BINARY 'Admin' - 性能退化明显：10 万行表上，
REGEXP查询可能比等值查询慢 50–100 倍；若数据量超百万，务必先用其他条件缩小结果集再套正则
MySQL 8.0+ 的 regexp_substr 能替代应用层解析吗？
REGEXP_SUBSTR() 确实能在 SQL 层提取子串（比如从日志中抽 IP），但它有硬性限制：
- 仅 MySQL 8.0.4+ 支持，低版本不可用
- 不支持捕获组命名（
(?<name>...)</name>）、反向引用（）等高级特性 - 性能比纯
REGEXP更差——每次调用都要做完整匹配 + 子串切分 - 实际场景中，它适合“一次性轻量提取”，比如：
SELECT REGEXP_SUBSTR(log, '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}') AS ip FROM logs LIMIT 100; - 但别指望它处理嵌套结构或上下文依赖内容（如提取 JSON 中某个 key 的 value），这类逻辑仍应交给应用层
真正容易被忽略的是：正则表达式本身没有“语义理解”能力，它只做字面模式匹配。哪怕写出了看似完美的邮箱校验 '^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+.[A-Za-z]{2,}$'，它依然会放过明显非法的 'a@b.c.d.e.f.g' ——这得靠业务规则兜底，而不是正则。
