MySQL中REGEXP基础写法为WHERE column_name REGEXP 'pattern'，返回1/0/NULL；需注意引号、转义（如'.'）、锚点显式使用（'^$'）、大小写由collation决定，且不支持\d、\s等PCRE特性。
MySQL 中 REGEXP 查询指定列的基础写法
直接用 WHERE column_name REGEXP 'pattern' 就能查匹配正则的行，不需要额外函数或子查询。它返回布尔结果（匹配为 1，不匹配为 0），可直接用于过滤。
常见错误是漏掉引号、忘记转义点号或混淆锚点含义。比如写 email REGEXP '@gmail.com' 会意外匹配 @gmailacom，因为 . 是元字符；必须写成 @gmail\.com。
-
^和$要显式加上才能控制“全串匹配”，否则只是“子串匹配” - MySQL 不支持
\d，得用[0-9]；\s也不支持，空格要写成字面空格或[[:space:]] - 大小写默认敏感（取决于列的 collation），如需忽略大小写，可用
LOWER(column_name) REGEXP 'pattern'或改用RLIKE（行为一致，但语义更清晰）
PostgreSQL 中用 ~ 替代 REGEXP 的关键差异
PostgreSQL 没有 REGEXP 关键字，而是用操作符 ~（区分大小写）和 ~*（不区分）。语法结构一样，但底层正则引擎是 POSIX ERE，不支持 MySQL 的 {n,m} 简写（需用 {n,m}，且必须启用 pg_regex 扩展才支持某些高级特性）。
容易踩的坑是误把 MySQL 写法直接搬过去——比如 name REGEXP '^A.*z$' 在 PostgreSQL 里会报错，得改成 name ~ '^A.*z$'；另外，PostgreSQL 中反斜杠在字符串里要双写，即 '\.' 才表示字面点号。
- 想匹配换行符？PostgreSQL 默认不跨行匹配，加标志
(?n)开启 DOTALL 模式（写在 pattern 开头） -
!~和!~*是否定形式，比NOT (col ~ 'p')更简洁 - 如果 pattern 来自参数或变量，推荐用
REGEXP_MATCHES()函数提取子组，~只适合布尔判断
SQLite 中无法直接用 REGEXP 的替代方案
SQLite 原生不支持 REGEXP，调用时会报错 no such function: REGEXP。必须先注册自定义函数（如 Python 的 sqlite3.Connection.create_function() 注入 re.search），或改用 GLOB（仅支持简单通配：*, ?, [abc]）凑合。
实际开发中，多数人选择在应用层过滤：先用 WHERE column LIKE '%@%.' 快速缩小范围，再用代码做正则校验。强行在 SQLite 里硬塞正则，性能差且不可移植。
- 若必须用正则且不能改应用逻辑，可用编译时启用
SQLITE_ENABLE_REGEXP的定制版 SQLite，但部署成本高 -
GLOB区分大小写，且不支持量词、分组、锚点等，WHERE email GLOB '*@gmail.com'只能粗筛，不能替代^/$精确控制 - 别依赖
PRAGMA compile_options查看是否支持——它只反映编译配置，不保证运行时可用
正则写错导致查不到数据的三个高频原因
不是正则本身难，而是 SQL 环境下几个隐性约束常被忽略：字符集、换行符处理、空值行为。比如 col REGEXP '^a' 对 NULL 值永远返回 NULL（不是 0），整行就被过滤掉——这跟 LIKE 行为一致，但新手常以为是正则没写对。
- MySQL 8.0+ 默认用 utf8mb4，但正则引擎按字节而非字符匹配；含 emoji 的字段用
.可能漏匹配 - 字段含回车
\r或换行\n？^和$默认只认字符串首尾，不认行首行尾；要用[\r\n]显式写出来 - 用
REGEXP 'a|b|c'代替IN ('a','b','c')看似省事，但索引完全失效，大数据量时响应明显变慢
真正卡住人的往往不是语法，而是正则在 SQL 引擎里怎么被解析、怎么跟 NULL/空格/编码共处——这些细节不试几次根本意识不到。
