MySQL 8.0 正则能力提升的核心是 REGEXP_LIKE 函数接口、标准化行为与上下文扩展，而非默认启用 ICU；它支持任意 SQL 位置调用、match_type 标志控制、NULL 返回 FALSE 等关键改进。
MySQL 8.0 的正则能力确实比 5.7 强，但根本原因不是“ICU 库集成”——MySQL 8.0 默认仍使用自己的正则引擎（基于 Henry Spencer 的 regex 实现），并未默认启用 ICU。官方文档和源码验证均表明：ICU 支持是可选编译选项，且生产环境极少启用；真正带来质变的是 REGEXP_LIKE 等函数接口 + 标准化行为 + 上下文扩展，而非底层引擎替换。
REGEXP_LIKE 函数让正则能“嵌入任意位置”
5.7 中 REGEXP 只是布尔运算符，只能出现在 WHERE 或 HAVING 子句里，不能当值用；8.0 的 REGEXP_LIKE() 是标准 SQL 函数，支持在 SELECT、ORDER BY、CASE、生成列、CHECK 约束中直接调用。
- 写
SELECT name, REGEXP_LIKE(email, '@') AS has_at FROM users→ 5.7 报错，8.0 正常 - 建检查约束
ADD CONSTRAINT chk_email CHECK (REGEXP_LIKE(email, '^[^@]+@[^@]+\.[^@]+$'))→ 5.7 不支持，8.0 原生支持 - 想按匹配结果排序：
ORDER BY REGEXP_LIKE(name, '^A') DESC→ 5.7 必须绕成ORDER BY (name REGEXP '^A') DESC，语义不清且不可移植
match_type 参数解决大小写与模式歧义问题
5.7 的 REGEXP 行为受 sql_mode（如 NO_BACKSLASH_ESCAPES）隐式影响，且无法显式控制大小写或换行模式；8.0 的 REGEXP_LIKE(expr, pat, match_type) 明确支持标志位组合：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
-
'i'：忽略大小写，替代过去靠LOWER()包裹的笨办法 -
'm'：多行模式，^和$可匹配每行首尾，而非仅整个字符串 -
'c'：强制区分大小写（覆盖 collation 默认行为） - 多个标志可叠加，如
'im'；5.7 完全没这个能力
NULL 处理更符合直觉，避免逻辑漏洞
5.7 中 NULL REGEXP '.*' 返回 NULL，在 WHERE 条件里会过滤掉整行（三值逻辑），极易引发数据丢失却无报错；8.0 的 REGEXP_LIKE(NULL, '.*') 明确返回 FALSE，行为稳定可预测。
- 场景：用户表有可空的
phone字段，想查“有效手机号”，写WHERE REGEXP_LIKE(phone, '^1[3-9]\d{9}$')→ 8.0 自动排除 NULL；5.7 必须显式加AND phone IS NOT NULL - 生成列依赖正则判断时，NULL 输入必须产出确定值，否则
STORED列无法构建索引
别被“ICU”误导：它不是默认特性，且有硬限制
虽然 MySQL 8.0 编译时可选 ICU（需配置 -DWITH_ICU=system），但实际部署中几乎不用，因为：
- ICU 模式下
REGEXP_LIKE()会禁用match_type中的'c'/'i'，改由 collation 控制，反而丧失灵活性 - ICU 不支持部分 5.7/8.0 原生语法（如
[:digit:]类 POSIX 字符组在 ICU 下可能不识别） - 开启 ICU 后，所有正则操作性能下降约 15–30%，且
EXPLAIN显示执行计划更难优化 - 官方 Docker 镜像、主流云厂商 RDS（如 AWS/Azure）均未启用 ICU，默认仍是原生引擎
真正值得投入的升级点，是把 5.7 里散落在 IF()、CASE、子查询里的正则判断，统一收口到 REGEXP_LIKE() 函数中——逻辑清晰、可维护、能进索引（配合生成列），这才是 8.0 正则升级的核心价值。
