mysql regexp 不支持 \d、\s 等 perl 风格简写，需用 [0-9]、[[:space:]] 替代；是否区分大小写由字段 collation 决定，regexp 本身无修饰符；无法走索引，大表慎用；5.7 与 8.0 行为差异大，推荐 8.0 使用 regexp_like() 并显式指定标志。
MySQL REGEXP 不支持 \d、\s 这类 Perl 风格简写
MySQL 的正则引擎基于 Henry Spencer 的正则库，不兼容 PCRE 或 JavaScript 风格的元字符。写 "\d+" 不会匹配数字，实际会被当作字面量 \d（即反斜杠 + d），多数情况直接报错或无结果。
- 用
[0-9]替代\d，[0-9]+才能匹配连续数字 - 空格用
[[:space:]]或字面空格，\s无效 - 字母数字组合用
[a-zA-Z0-9]，别信\w（MySQL 不识别） - 中文需确保字段是 utf8mb4 且排序规则支持，比如
utf8mb4_unicode_ci，否则[一-龯]可能漏字
区分大小写：取决于字段的 collation，不是 REGEXP 自身开关
很多人以为加 BINARY 或写 REGEXP BINARY 就能强制大小写敏感——其实 MySQL 不支持这种语法。REGEXP 本身没有修饰符参数，是否区分大小写完全由字段的排序规则（collation）决定。
-
utf8mb4_general_ci和utf8mb4_0900_as_cs行为不同：_ci结尾 = case-insensitive，_cs或_bin结尾 = case-sensitive - 临时强制区分大小写：把字段转成
BINARY类型再匹配，例如CAST(col AS BINARY) REGEXP 'Abc' - 线上表改 collation 风险高，建议查前先
SHOW FULL COLUMNS FROM table_name LIKE 'col_name'确认当前规则
REGEXP 在 WHERE 中无法走索引，大表慎用
哪怕字段上有索引，col REGEXP '^abc' 也几乎不会命中索引（MySQL 8.0.4+ 对前缀固定模式有极有限优化，但不可依赖）。本质是正则需要逐行展开字符串做状态机匹配，和 B+ 树的有序查找逻辑冲突。
MySQL（Linux）
下载
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
- 替代方案优先考虑：
col LIKE 'abc%'（可走索引）、LEFT(col, 3) = 'abc'、或冗余生成一个规范化的前缀字段单独建索引 - 若必须用正则，尽量缩小数据集：先用主键/时间范围等高效条件过滤，再对结果集做
REGEXP - 执行前一定看
EXPLAIN，如果type是ALL且rows很大，说明正在全表扫描
MySQL 5.7 和 8.0 的 REGEXP 行为差异容易踩坑
MySQL 8.0 重写了正则引擎，引入了 REGEXP_LIKE() 函数，并支持部分 POSIX ERE 特性（如 +、?、|），但默认仍禁用某些功能；5.7 则更保守，连 + 都要写成 {1,} 才安全。
- 跨版本迁移时，
'a+b' REGEXP 'a+b'在 8.0 返回 1，在 5.7 返回 0（因为 5.7 把+当字面量） - 稳妥写法：用
{1,}代替+，{0,1}代替?，避免版本兼容问题 - 8.0 推荐用
REGEXP_LIKE(col, pattern, 'c')显式指定大小写（'c'= case-sensitive），比隐式 collation 更可控 - 错误信息提示也不同：5.7 常报
Got error 'repetition-operator operand invalid' from regexp，8.0 更具体，比如指出哪个括号没闭合
正则在 MySQL 里从来不是“能用就行”的功能——它既慢又脆，还藏在 collation 和版本差异的缝隙里。真正要用，得先确认字段编码、查清当前 MySQL 版本的 regex 引擎能力边界，再决定是硬上还是绕道。
