MySQL的REGEXP是逐行逐字符回溯匹配的操作符，不支持全局标志、默认不区分大小写（受collation影响），不支持Unicode属性类和懒惰量词；^和$锚定字符串首尾，但遇换行符行为异常；性能差，无法走B-Tree索引，需配合LIKE等前置过滤。
REGEXP 在 MySQL 中的匹配行为和默认模式
MySQL 的 REGEXP（或同义词 RLIKE）是**逐行、逐字符回溯匹配**，不支持全局标志（如 g）、不区分大小写默认开启（取决于列的 collation），且**不支持 Unicode 属性类（如 \p{L}）或懒惰量词（*?）**。这意味着你写的正则在 Python 或 JavaScript 里能跑，放到 MySQL 里很可能报错或行为异常。
常见踩坑点：
- 用
[a-z]+匹配中文？不行——MySQL 正则引擎按字节处理，UTF8MB4 下中文是 3–4 字节，[a-z]只匹配 ASCII 小写字母 - 写
^abc$以为只匹配完整字段？错——MySQL 的^和$锚定的是**整个字符串首尾**，但若字段含换行符（\n），^可能匹配到中间行首（取决于版本和 SQL mode） - 过度依赖
.*：回溯深度大，字段越长越慢，尤其配合可变长度前缀时（如a.*b匹配 "aaab" 会尝试多种分割）
提高 REGEXP 查询性能的关键实操点
REGEXP 无法使用普通 B-Tree 索引加速，但可以通过「前置固定字符串 + REGEXP」组合规避全表扫描。
例如查邮箱域名以 gmail.com 结尾：
SELECT * FROM users WHERE email LIKE '%@gmail.com' AND email REGEXP '@gmail\.com$';
这里 LIKE '%@gmail.com' 允许走索引（如果 email 有索引），快速过滤出候选行，再用 REGEXP 做精确校验。注意点：
- 必须用
\.转义点号，否则@gmail.com中的.会匹配任意字符 - 避免写成
email REGEXP '.*@gmail\.com$'——前面的.*让优化器放弃索引利用 - 若字段经常按某模式查询（如手机号、身份证），考虑增加生成列 + 索引：
ALTER TABLE users ADD COLUMN phone_prefix VARCHAR(3) STORED AS (SUBSTR(phone, 1, 3)) INDEX;
常用但易错的 REGEXP 写法对照
下面这些看似直观的写法，在 MySQL 中要么无效，要么语义不同：
-
'[0-9]{5}'✅ 可用，匹配连续 5 位数字 -
'\d{5}'❌ MySQL 不识别\d，必须写[0-9] -
'abc|def'✅ 支持基本分支，但优先级低，'ab(c|d)ef'才等价于'abcef|abdef' -
'a+b+'✅ 匹配至少一个a后接至少一个b；但'a++b'❌ 不支持 possessive quantifier -
'[^\n]+'⚠️ 表面想匹配“非换行符”，实际在 MySQL 中^在字符组内表示取反，\n却不被识别为换行符字面量——应改用'[^[:cntrl:]]+'或直接避开
替代方案：什么时候不该硬上 REGEXP
当需求满足以下任一条件，优先考虑非正则解法：
- 只需前缀/后缀/子串匹配：
LIKE 'prefix%'、RIGHT(col, 4) = '.pdf'、INSTR(col, 'http') > 0都比REGEXP快数倍 - 需校验格式（如邮箱、手机号）：应用层用成熟库（如 Python 的
email-validator）更准，MySQL 正则无法覆盖所有 RFC 规则 - 要提取子串（如从 JSON 中取值）：MySQL 8.0+ 用
JSON_EXTRACT()，5.7 用SUBSTRING_INDEX()组合，别用REGEXP_SUBSTR()（8.0 才有，且性能差）
真正需要 REGEXP 的场景其实很窄：日志字段解析（如 Nginx access log）、脏数据清洗（混合分隔符）、或 legacy 系统中无法改结构的模糊分类。用之前先 explain，确认是否触发了全表扫描——那多半该重构了。
