REGEXP和RLIKE完全等价，是MySQL中可互换使用的正则匹配操作符；二者均返回1（匹配成功）或0（失败），底层调用同一正则引擎，区别仅在于命名习惯。
MySQL的REGEXP和RLIKE到底有什么区别？
完全没区别。REGEXP 和 RLIKE 是同义词，MySQL里可以互换使用，底层调用同一套正则引擎。选哪个纯看团队习惯或SQL可读性偏好——比如写日志分析时用 RLIKE 更像自然语言（“matches regex”），但函数名本身不改变行为。
注意：MySQL 8.0 之前用的是 Henry Spencer 的正则库，功能较弱；8.0+ 切换为 ICU 库，支持 Unicode、命名捕获组（但仅限 REGEXP_SUBSTR 等衍生函数，基础 REGEXP 仍不支持分组引用）。
哪些正则语法在MySQL中实际不可用？
最常踩坑的是过度依赖 PCRE 或 JavaScript 风格写法。MySQL（尤其 8.0 前）不支持：
-
\d、\w、\s—— 必须写成[0-9]、[a-zA-Z0-9_]、[[:space:]] - 反向引用（如
(\w+)\1）—— 语法不报错，但匹配逻辑不可靠，慎用 - 非贪婪量词（
.*?）—— MySQL 全部按贪婪处理，.*?等价于.* - Lookahead / Lookbehind 断言 —— 完全不识别，会直接报错
ERROR 1139 (HY000): Got error 'invalid character class' from regexp
实操建议：用 [[:digit:]] 代替 \d，用 [[:alpha:]] 代替 [a-zA-Z]，兼容性更稳。
如何高效匹配带分隔符的多值字段（比如CSV格式的tag列）？
别真当 CSV 解析——MySQL 没有原生 CSV tokenizer。常见错误是写 tags REGEXP '(^|,)php(,|$)' 来找独立单词 "php"，但这在含 "php7" 或 "hyperphp" 时会误判。
正确思路是用 word boundary 模拟，但 MySQL 不支持 \b，得手动构造：
WHERE tags REGEXP '(^|[^a-zA-Z0-9_])php([^a-zA-Z0-9_]|$)'
说明：
-
(^|[^a-zA-Z0-9_])表示开头 或 非单词字符（避免 "xphp" 匹配） -
([^a-zA-Z0-9_]|$)表示结尾 或 非单词字符（避免 "phpx" 匹配） - 如果字段是 utf8mb4 + MySQL 8.0+，可用
[[:punct:]]替代[^a-zA-Z0-9_]，更准确覆盖标点
性能提示：这种正则无法走索引，字段量大时务必加前置条件过滤（比如先 WHERE status = 'active' 缩小结果集）。
为什么REGEXP_SUBSTR在8.0里返回NULL？
大概率是没匹配上，或者参数顺序搞错了。REGEXP_SUBSTR 要求：字符串、模式、起始位置（默认1）、匹配序号（默认1）、匹配模式（可选）。最容易忽略的是第4个参数——它不是“是否全局”，而是“取第几个匹配项”。
例如：
SELECT REGEXP_SUBSTR('a1b2c3', '[0-9]'); -- 返回 '1'SELECT REGEXP_SUBSTR('a1b2c3', '[0-9]', 1, 2); -- 返回 '2'，不是 '12'如果想取全部数字拼一起，不能靠这个函数，得用 REGEXP_REPLACE 配合空替换：
SELECT REGEXP_REPLACE('a1b2c3', '[^0-9]', ''); -- 返回 '123'另外注意：MySQL 对大小写敏感取决于字段 collation，若要忽略大小写，显式加 COLLATE utf8mb4_0900_as_cs 或改用 REGEXP_LIKE(str, pat, 'i')（8.0.22+）。
正则在 MySQL 里从来不是万能胶，它适合做轻量文本探查，不适合替代应用层解析。真正复杂的模式（比如嵌套括号、平衡引号），尽早移出 SQL，在代码里用成熟正则引擎处理。
