MySQL的REGEXP与RLIKE完全等价，支持POSIX ERE子集（如^、$、.、[abc]、a*、a|b、[:digit:]），但不支持捕获组、反向引用、lookahead等高级特性；8.0+用ICU引擎，5.7用Henry Spencer库，性能差因无法走索引，应优先用LIKE或生成列优化。
MySQL 的 REGEXP 运算符支持基础正则匹配，但不支持 PCRE 或现代正则的多数高级特性（比如捕获组、反向引用、lookahead），用之前得先认清它的能力边界。
REGEXP 和 RLIKE 是一回事吗？
是的，REGEXP 和 RLIKE 完全等价，都是 MySQL 中的正则匹配运算符，语法和行为无区别。选哪个纯看团队习惯或可读性偏好。
SELECT * FROM users WHERE name REGEXP '^A';-
SELECT * FROM users WHERE name RLIKE '^A';—— 效果完全相同 - 注意：MySQL 8.0+ 默认使用 ICU 正则引擎（更标准），但旧版本（如 5.7）用的是 Henry Spencer 的 regex 库，对 Unicode 支持弱，
\w只匹配 ASCII 字母数字
哪些正则语法 MySQL 真的能用？
MySQL 支持 POSIX ERE（扩展正则表达式）子集，常见可用写法包括：
-
^和$：行首/行尾锚点（注意：不是字符串首尾，而是字段值整体的首尾） -
.：匹配任意单字符（除换行符；MySQL 字段一般无换行，影响小） -
[abc]、[^0-9]：字符类，支持取反 -
a*、a+、a?：量词，但a{2,5}在 MySQL 5.7 不支持，8.0+ 才支持 -
a|b：多选分支（注意：优先级低，建议加括号，如(cat|dog)） -
[:digit:]、[:alpha:]：POSIX 字符类，比[0-9]更安全（尤其涉及排序规则时）
不可用的典型写法：d、s、(?i)、、.*?（非贪婪不支持）、u4F60（Unicode 转义需 MySQL 8.0+ 且正确设置 collation）
为什么 REGEXP 性能差？怎么避免滥用？
REGEXP 无法使用索引（即使字段有索引），执行时必走全表扫描，数据量稍大就明显变慢。
- 替代方案优先级：前缀匹配 →
LIKE 'abc%'（可用索引）；精确值 →= 'value'；范围 →BETWEEN - 若必须正则，尽量缩小扫描范围：先用其他条件过滤，再在结果集上
REGEXP，例如WHERE status = 'active' AND email REGEXP '@gmail\.com$' - 避免在
WHERE中对函数结果做正则，如UPPER(name) REGEXP 'A.*'—— 这会让索引彻底失效 - MySQL 8.0+ 可考虑生成列 + 索引：比如为邮箱域名建虚拟列
domain VARCHAR(64) STORED AS (SUBSTRING_INDEX(email, '@', -1))，再对domain做等值查询
常见错误与绕过方式
实际写的时候容易踩几个坑：
-
点号没转义却想匹配字面量：写成
WHERE url REGEXP 'https://example.com'会出错，因为.和/都是元字符，应写成'https://example\.com'（注意双反斜杠，SQL 字符串里最终传给正则引擎的是单反斜杠） -
中文或特殊字符匹配失败：确认字段和连接的
collation支持 utf8mb4，否则[一-龥]类写法可能不生效；更稳妥用CONVERT(col USING utf8mb4) REGEXP '...' -
空值导致整行被忽略：
col REGEXP 'xxx'对NULL返回NULL（即不满足 true），如需包含空值，显式写col REGEXP 'xxx' OR col IS NULL -
大小写敏感问题：默认行为取决于字段 collation；若要强制不区分大小写，用
COLLATE utf8mb4_0900_as_cs不行，得改用REGEXP BINARY控制（加BINARY变区分，不加则按 collation 规则）
SELECT * FROM logs WHERE message REGEXP BINARY 'ERROR'; -- 区分大小写 SELECT * FROM logs WHERE message REGEXP 'error'; -- 取决于 message 列的 collation
真正要用好 REGEXP，关键是别把它当万能胶——先想有没有更高效、更确定的替代方式；真要上，就老老实实按 POSIX ERE 写，别套 JavaScript 或 Python 里的习惯。
