MySQL用[0-9]或[:digit:]查数字，不支持d；PostgreSQL需E'\d'；SQL Server无原生正则，靠LIKE；SQLite默认REGEXP无效，须手动注册函数。
MySQL 用 REGEXP 查含数字的行，但注意默认不区分大小写且不支持 d
MySQL 的正则引擎不识别 d，直接写 WHERE col REGEXP 'd' 会报错或不生效。真正能用的是字符类 [0-9] 或简写 [[:digit:]]（POSIX 写法，更兼容）。比如查用户名里带数字的记录：
SELECT * FROM users WHERE username REGEXP '[0-9]';注意：MySQL 8.0+ 支持
REGEXP_LIKE() 函数，语法更清晰，但老版本只能用 REGEXP 操作符。
PostgreSQL 要用 ~ 操作符，d 可用但需加 E'' 前缀
PostgreSQL 默认支持标准 PCRE 风格的 d，但必须用带 E 前缀的字符串字面量，否则反斜杠会被当普通字符处理。错误写法：WHERE col ~ 'd'（实际匹配的是字母 d）；正确写法：
SELECT * FROM logs WHERE message ~ E'\d';常见坑：漏掉一个反斜杠 ——
E'd' 会报错，必须是 E'\d'；另外 ~* 是忽略大小写的变体，对数字无效，但写错可能影响后续逻辑。
SQL Server 没原生正则，得靠 LIKE 或 CLR/外部函数
SQL Server 2016+ 仍不支持正则，LIKE 是最常用替代方案，但能力有限：
SELECT * FROM products WHERE name LIKE '%[0-9]%';这个能查出含任意数字的行，但无法表达“至少两个连续数字”或“开头是数字”这类需求。如果真需要复杂匹配，得启用 CLR 集成并部署自定义函数，或者把数据拉到应用层处理。别指望
PATINDEX 能替代正则 —— 它只返回位置，不支持分组或量词。
SQLite 的 REGEXP 是占位符，不启用就永远返回 NULL
SQLite 编译时默认禁用正则支持，即使你写了 WHERE col REGEXP '[0-9]'，结果也全是 NULL（不是空结果集，是每行都判为 false）。必须在连接数据库前注册 regexp 函数，例如 Python 中用 sqlite3.connect() 后调用 create_function('regexp', 2, re.search)。没有这步，所有 REGEXP 表达式都失效，而且不会报错，容易误以为数据没匹配上。
正则在 SQL 里从来不是“开箱即用”的功能，每个数据库的语法、转义规则、启用条件都差得远；最隐蔽的坑往往不在写法，而在你根本没意识到那个函数压根没生效。
