MySQL中如何运用正则表达式进行高级查询？

是的，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>...)）、反向引用（）等高级特性
• 性能比纯 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,}$'，它依然会放过明显非法的 '[email protected]' ——这得靠业务规则兜底，而不是正则。