mysql中regexp/rlike需用'[0-9]’而非’d’，单引号包裹模式，^$匹配整字段，大小写由collation决定；postgresql用’~’区分大小写、’~*’不区分，反斜杠需双写；sql server无原生正则，依赖like/patindex或应用层处理。
MySQL 的 REGEXP 和 RLIKE 怎么写才不报错
MySQL 不支持标准 POSIX 或 PCRE 正则，只提供有限的扩展正则（类似 egrep），且大小写敏感性取决于字段排序规则（collation）。常见错误是直接套用 JavaScript 或 Python 的写法，比如用 d 匹配数字——MySQL 5.7 及以前根本不认这个转义，得写成 [0-9]。
实操建议：
-
REGEXP和RLIKE完全等价，选哪个纯看团队习惯，但别混在同一个 SQL 里来回切 - 字符串字面量必须用单引号，双引号在严格模式下会报错：
WHERE name REGEXP "^[A-Z]"→ 改成WHERE name REGEXP '^[A-Z]' - 想忽略大小写？别依赖
i标志（MySQL 不支持），改用COLLATE utf8mb4_0900_as_cs显式指定，或直接用LOWER()包裹字段和模式 - 锚点
^和$是行首/行尾，不是整个字段起止——MySQL 把字段当单行处理，所以^abc$能匹配完整值为 “abc” 的记录
PostgreSQL 的 ~、~* 和 POSIX 模式要注意啥
PostgreSQL 正则能力最强，但默认走的是 POSIX ERE（扩展正则表达式），不支持 d、w 这类 perl 风格简写（除非开启 pg_regex 兼容层，但不推荐）。最常踩的坑是忘记转义反斜杠：你在字符串里写 'd+'，实际传给正则引擎的是 d+；如果只写 'd+'，会被当作普通字符 d+ 处理。
实操建议：
-
~区分大小写，~*不区分，别用ILIKE去凑正则功能（它不支持量词和分组） - 捕获组用
()，但提取内容得靠substring()或regexp_matches()，select col ~ '(d+)' FROM t只返回布尔值 - 性能敏感场景慎用
regexp_replace()在 WHERE 中——它无法走索引，比LIKE慢一个数量级 - 模式里含换行符？默认
.不匹配换行，加标志's'：col ~ '(?s)start.*end'
SQL Server 没有原生正则，替代方案怎么选
SQL Server 2017+ 仍无内置正则函数，PATINDEX() 和 LIKE 是主力，但能力极弱：不支持分组、不支持量词嵌套、不能反向引用。很多人强行用 CLR 或外部 Python 调用，结果部署卡死、权限难批、运维翻车。
实操建议：
-
LIKE足够应付简单模式：name LIKE '[A-Z]%[0-9]'表示“大写字母开头 + 数字结尾”，但%是任意长度，_是单字符，别混淆 -
PATINDEX('%[^a-zA-Z0-9]%', col)可定位第一个非法字符位置，适合清洗场景，但返回 0 表示没找到——注意判空逻辑 - 真要复杂匹配？优先把数据拉到应用层处理。SQL Server 的字符串函数（
STRING_SPLIT、TRANSLATE）配合 CTE 已能覆盖 70% 的清洗需求 - 别信网上“用 xml + XQuery 模拟正则”的方案，维护成本高，SQL Server 2019 后还可能因安全策略被禁用
跨数据库写正则时，哪些写法最容易出兼容问题
看似一样的正则，在不同数据库里行为可能天差地别。最危险的是字符类和量词：MySQL 的 [[:digit:]] 在 PostgreSQL 里要写成 [[:digit:]]（一样），但在 SQL Server 里根本无效；而 a{2,4} 在 MySQL 和 PostgreSQL 都支持，SQL Server 的 LIKE 却只能靠 aa、aaa、aaaa 手动枚举。
实操建议：
- 避免用
（单词边界）：MySQL 不支持，PostgreSQL 需要[:<:>/<code>[:>:]模拟，SQL Server 彻底没戏 - 量词优先用
*和+，少用{n,m}——sqlite 完全不支持花括号语法 - 如果必须多库兼容，把正则逻辑下沉到应用代码，SQL 层只做基础过滤。数据库不是正则引擎，硬塞只会让查询变慢、可读性归零
- 测试时别只查“能匹配”，重点验证“不该匹配的有没有误中”——比如
'[0-9]+'在 MySQL 里会把 “abc123def” 整个字段判为 true，但你本意可能是“字段纯数字”
事情说清了就结束。正则不是 SQL 的强项，越想在数据库里做完所有匹配，越容易掉进语法差异和性能黑洞里。