MySQL的REGEXP支持POSIX ERE子集，包括^、$、.、[]、[^]、*、+、?、{n,m}、|、[:digit:]等；不支持d、w、s等PCRE简写，且无法利用索引加速。
MySQL的REGEXP支持哪些正则语法？
MySQL的REGEXP（或别名RLIKE）底层基于Henry Spencer的正则库，不支持PCRE、JavaScript或Python中的多数现代特性，比如非捕获组(?:...)、反向断言、K、Unicode属性等。它只支持基本POSIX ERE（扩展正则表达式）子集。
常见可用语法包括：^、$、.、[abc]、[^abc]、a*、a+、a?、a{2,5}、(ab|cd)、[[:digit:]]、[[:alpha:]] 等字符类。
注意：d、w、s 这类简写不被识别，必须用[[:digit:]]、[[:alnum:]]、[[:space:]] 替代；否则会字面匹配反斜杠和字母，导致意外失败。
如何正确匹配中文、数字混合的字符串？
中文在MySQL中属于多字节字符，但REGEXP按字节而非字符处理——只要排序规则（collation）支持UTF8MB4（如utf8mb4_0900_as_cs），且字段是TEXT或VARCHAR类型，就能正常匹配中文。
例如：查找“订单号：OD123456 或 订单号：CN中文789”这类字段：
SELECT * FROM logs
WHERE content REGEXP '^订单号：[A-Z]{2}[0-9]{6}$|^订单号：[A-Z]{2}[^[:ascii:]]+[0-9]{3}$';关键点：
-
[^[:ascii:]]+匹配一个及以上非ASCII字符（覆盖中文、日文等） - 用
^和$锚定整字段，避免子串误匹配 - 多个模式用
|连接，但注意优先级：括号必须显式包裹各分支 - 若字段含换行符，
.无法跨行匹配，且^/$仅匹配整体首尾，不匹配每行——MySQL不支持/m修饰符
为什么REGEXP查询慢？有没有替代方案？
REGEXP 无法使用B+树索引加速，即使字段上有索引，执行时仍为全表扫描。尤其在千万级表上，一个WHERE content REGEXP '...'可能秒变慢查询。
可考虑的替代路径：
- 提前提取结构化字段：如把“邮箱”“手机号”“订单ID”单独存为列，加索引后用
=或LIKE 'prefix%'查询 - 使用全文索引（
FULLTEXT）配合MATCH ... AGAINST做关键词检索（但不支持正则逻辑） - 对高频正则模式，用生成列（generated column）预计算布尔值，再对该列建索引
ALTER TABLE users ADD is_valid_email TINYINT AS (content REGEXP '^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}$') STORED;然后查询：WHERE is_valid_email = 1
区分大小写与排序规则的影响
REGEXP 默认区分大小写，但实际行为取决于字段的排序规则（collation）：
-
utf8mb4_0900_as_cs（case-sensitive）→A≠a -
utf8mb4_0900_as_ci（case-insensitive）→A=a -
utf8mb4_bin→ 按字节比较，中文也区分不同编码字节序列
验证当前字段行为：
SHOW FULL COLUMNS FROM table_name LIKE 'column_name';
若需强制不区分大小写，不要依赖LOWER()包装字段（破坏索引且低效），而应直接修改列的collation为_ci结尾的版本。
正则本身没有i标志，大小写行为完全由collation决定——这点容易被忽略，查不出结果时先确认collation是否符合预期。
