mysql 8.0.4+才真正支持regexp_like()，需用'c'/'i'/'m'标志而非'icase'，pattern不加/包裹，且re2引擎不支持反向引用和环视。

MySQL 8.0+ 的 REGEXP_LIKE() 怎么写才不报错

MySQL 在 8.0.4+ 才真正支持标准正则匹配函数，低版本用 REGEXP 或 RLIKE 只能返回布尔值，没法提取或分组。很多人直接照搬 PostgreSQL 的写法，比如加 icase 标志，结果报 Unknown operator 'icase'。

实操建议：

• REGEXP_LIKE(str, pattern, 'c')：'c' 表示区分大小写（默认），'i' 表示不区分，'m' 启用多行模式（^/$ 匹配每行首尾）
• pattern 中不能用 / 包裹，直接写表达式，例如验证手机号：REGEXP_LIKE(phone, '^[1][3-9]\d{9}$')
• MySQL 正则引擎是 RE2，不支持反向引用（\1）、环视（(?=...)）等高级特性，别往里塞 PCRE 风格的写法

PostgreSQL 用 ~ 和 ~* 做数据清洗时的边界问题

PostgreSQL 的 ~（区分大小写）和 ~*（忽略大小写）看着简单，但实际用在 WHERE 或 CASE WHEN 里，容易漏掉空值和空白字符串——它们既不匹配也不报错，只是静默跳过。

常见错误现象：字段含空格或 NULL，验证邮箱的规则 email ~* '^.+@.+..+$' 返回 false，但你查不到这些记录，因为 NULL ~* 'xxx' 结果是 NULL，不是 false。

实操建议：

• 必须显式处理空值：email IS NOT NULL AND TRIM(email) != '' AND email ~* '^.+@.+..+$'
• 避免在索引字段上用函数包裹再正则，比如 LOWER(email) ~ 'xxx' 会失效索引；优先用 ~*，它底层已做优化
• 如果要批量清理脏数据，用 NOT (email ~* 'pattern') 比 !~* 更可读，也更少出错

SQL Server 的 LIKE 为什么不能替代正则？

SQL Server 直到 2022 版才原生支持 STRING_SPLIT 和 TRANSLATE，但依然没内置正则函数。有人硬用 LIKE 模拟邮箱验证，写成 email LIKE '%_@_%._%'，结果把 test@.com、@domain.com 全放过了。

根本原因：LIKE 只有通配符（%、_、[abc]），不支持量词、锚点、分组，也没办法否定字符集（比如“非数字”只能靠 NOT LIKE '[0-9]%' 这种绕路写法）。

实操建议：

• 简单格式校验（如固定长度数字码）可用 LIKE，但涉及「至少一个」、「必须包含」、「不能以某字符开头」这类逻辑，就该换方案
• SQL Server 2016+ 可调用 CLR 函数注入正则，但需开启 TRUSTWORTHY，生产环境通常被禁用；更现实的做法是在应用层验证，或用 OPENJSON + 外部 API 做异步校验
• 如果必须 SQL 内完成，用 PATINDEX('%pattern%', str) > 0 比 LIKE 稍灵活，但仍受限于通配符能力

正则写进 CHECK 约束后，插入失败却不报具体哪条不合规

很多人把 REGEXP_LIKE 或 ~* 直接塞进 CHECK 约束，以为能自动拦截非法数据。但一旦批量插入（INSERT ... SELECT 或 CSV 导入），报错只显示 check constraint violated，不会告诉你第几行、哪个字段、为什么失败。

这导致排查成本陡增，尤其当表有多个正则约束时，根本不知道是邮箱格式错了，还是用户名含了 emoji，或是时间字符串少了冒号。

实操建议：

• 不要把复杂正则塞进 CHECK；优先用应用层验证 + 数据库唯一/非空约束兜底
• 如果必须用，搭配生成列（generated column）提前计算验证结果，例如：is_valid_email BOOLEAN GENERATED ALWAYS AS (email ~* '^.+@.+..+$') STORED，再对这个列建 CHECK
• 导入前先用 SELECT 扫一遍异常数据：SELECT id, email FROM users WHERE NOT (email ~* 'pattern')，比等报错再查快得多

正则在 SQL 里从来不是万能胶——它跑得慢、难调试、跨数据库不兼容，最麻烦的是，错误信息永远比你想象中更沉默。