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 里的习惯。
