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 完全等价,都是 MySQL 中的正则匹配运算符,语法和行为无区别。选哪个纯看团队习惯或可读性偏好。
SELECT * FROM users WHERE name REGEXP '^A';SELECT * FROM users WHERE name RLIKE '^A'; —— 效果完全相同\\w 只匹配 ASCII 字母数
字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 无法使用索引(即使字段有索引),执行时必走全表扫描,数据量稍大就明显变慢。
LIKE 'abc%'(可用索引);精确值 → = 'value';范围 → BETWEEN
REGEXP,例如 WHERE status = 'active' AND email REGEXP '@gmail\\.com$'
WHERE 中对函数结果做正则,如 UPPER(name) REGEXP 'A.*' —— 这会让索引彻底失效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
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 里的习惯。