MySQL中REGEXP是POSIX ERE语法的子串匹配运算符，右侧为正则表达式，返回1/0/NULL；不支持PCRE特性，不走索引，区分大小写由字段collation决定。
MySQL 中 REGEXP 运算符的写法和基本行为
MySQL 的 REGEXP（或同义词 RLIKE）是用于模式匹配的二元运算符，**右侧必须是正则表达式字符串，左侧是待匹配的字段或值**。它返回 1（匹配）、0（不匹配）或 NULL（任一操作数为 NULL）。注意：MySQL 使用的是 **POSIX ERE（扩展正则表达式）语法**，不是 PCRE，不支持 d、s、非贪婪量词或捕获组等常见现代特性。
常见错误现象：
- 写成 WHERE column REGEXP 'pattern' ESCAPE '' —— ESCAPE 不适用于 REGEXP，那是 LIKE 用的；
- 误以为 ^ 和 $ 默认锚定整列值 —— 实际上 MySQL 的 REGEXP 是“子串匹配”，'a' 能匹配 'abc'，除非显式写成 '^a$'。
常用元字符和必须转义的字符
MySQL 的正则引擎对反斜杠处理较特殊：在字符串字面量中，MySQL 先解析一次转义，再传给正则引擎。因此要匹配一个字面量反斜杠 ，需写四个：'\\'；要匹配点号 .，得写 '\.'（因为 '.' 中的 . 会被 MySQL 字符串层吃掉第一个反斜杠，只剩 .，变成任意字符）。
-
^匹配行首（注意：不是“字段开头”，而是“字段值开头”） -
$匹配行尾（同理，是字段值结尾） -
[abc]字符类，匹配其中任一字符；[^abc]表示否定 -
[a-z]支持范围，但受当前 collation 影响（如utf8mb4_0900_as_cs下大小写敏感） -
*匹配前一项零次或多次；+一次或多次；?零次或一次（ERE 标准） - 要匹配字面量
^、$、.、*、+、?、[、]、|、(、)，一律加\前缀
区分大小写与排序规则的影响
REGEXP 是否区分大小写，**完全取决于字段的 collation**，而不是 SQL 模式或服务器配置。例如：
SELECT 'ABC' REGEXP 'abc'; -- 若字段是 utf8mb4_general_ci，则返回 1；若是 utf8mb4_0900_as_cs，则返回 0
无法通过 BINARY 强制区分（BINARY 'ABC' REGEXP 'abc' 语法错误），但可用 COLLATE 显式指定：
SELECT 'ABC' COLLATE utf8mb4_0900_as_cs REGEXP 'abc'; -- 返回 0
实际使用建议：
- 如果业务要求严格区分大小写，确保字段定义时用了 _as_cs 或 _bin collation；
- 不要依赖默认 collation 做关键匹配逻辑；
- 测试时务必用真实数据和真实 collation 验证，避免开发环境和生产环境结果不一致。
性能注意事项和替代方案
REGEXP 无法使用普通 B+Tree 索引加速，全表扫描不可避免。即使字段有索引，只要写了 REGEXP，优化器基本放弃走索引（极少数前缀固定且无回溯的简单模式除外，但不可靠）。
- 能用
=、IN、BETWEEN就别用REGEXP - 以固定前缀开头的匹配（如“以 abc 开头”），优先用
LIKE 'abc%'，它可走索引 - 需要高频正则查询的场景，考虑在应用层做匹配，或引入 Elasticsearch / Redis 模块等专用工具
- MySQL 8.0+ 的
REGEXP_INSTR、REGEXP_SUBSTR等函数功能更强，但同样不走索引
真正麻烦的不是语法记不住，而是忘记它不走索引、不支持常见 PCRE 特性、且 collation 会静默改变行为——这三个点一旦漏查，线上就容易出慢查询或匹配错误。
