PATINDEX返回模式首次出现位置，0表示未匹配；查含数字字符串用PATINDEX('%[0-9]%', username) > 0，需注意%通配符不可省略、方括号为字符类、不支持复杂正则。
SQL Server 用 PATINDEX 查含数字的字符串
SQL Server 没有原生正则支持（2016+ 虽支持 STRING_SPLIT 和部分 JSON 函数，但 REGEXP 仍不可用），PATINDEX 是最直接、兼容性最好的选择。它返回模式首次出现的位置，为 0 表示未匹配。
查字段中「至少含一个数字」的记录，写法是：
SELECT * FROM users WHERE PATINDEX('%[0-9]%', username) > 0;注意：%[0-9]% 中的方括号是字符类，不是通配符；开头结尾的 % 是通配符，表示任意前后缀。漏掉任一 % 都会导致逻辑错误——比如写成 [0-9] 会只匹配「整个字段恰好是一个数字」。
-
PATINDEX区分大小写取决于列的排序规则（collation），若需忽略大小写，确保列使用_CI（Case-Insensitive）结尾的排序规则，或显式转换：PATINDEX('%[0-9]%', UPPER(username)) - 性能上，该条件无法走索引（除非建计算列 + 索引），大数据量时慎用于高频查询
- 不能表达「连续两位数字」或「以数字开头」等更复杂逻辑——得靠多个
PATINDEX组合或改用 CLR 正则函数
MySQL / PostgreSQL 用 REGEXP 或 ~ 匹配数字
MySQL 8.0+ 和 PostgreSQL 原生支持正则，语法更直观，但操作符和写法不同。
MySQL：
SELECT * FROM users WHERE username REGEXP '[0-9]';
PostgreSQL：
SELECT * FROM users WHERE username ~ '[0-9]';
两者都支持常见正则语法，例如：
-
'^[0-9]'表示「以数字开头」 -
'[0-9]{2,}'表示「含至少两个连续数字」 - PostgreSQL 还支持
~*（忽略大小写）、!~（取反）
注意：MySQL 5.7 及更早版本的 REGEXP 不支持 Unicode 字符类（如 \d），必须用 [0-9]；而 MySQL 8.0+ 和 PostgreSQL 支持 \d，但语义一致，可互换。
为什么不用 LIKE 模拟数字匹配
LIKE 的 [0-9] 写法看似可行，但它只在 SQL Server 中被支持（且仅限于 PATINDEX 和 LIKE 的字符范围语法），其他数据库不识别方括号内的范围表达式。
常见误写：
WHERE username LIKE '%[0-9]%'
这在 MySQL 或 PostgreSQL 中不会报错，但会被当作字面量匹配——即查找包含 [、0、-、9、] 这五个字符的字符串，完全不是本意。
所以：LIKE 适合固定模式（如前缀、后缀），不适合「任意位置存在某类字符」这种需求；强行用 LIKE 枚举所有单数字（'%0%' OR '%1%' OR ...）不仅难写，还严重损害可读性和执行计划稳定性。
跨数据库可移植的兜底方案：用函数逐字符判断
如果必须兼容多种数据库且无法用正则（如旧版 MySQL 或某些嵌入式 SQLite 场景），可用标量函数遍历字符串。SQLite 示例（需启用 load_extension 或使用内置 instr）：
SELECT * FROM users WHERE instr(username, '0') OR instr(username, '1') OR ... OR instr(username, '9');
但这只是理论可行，实际没人这么写——太冗长、难维护、性能差。真正需要跨库时，建议在应用层过滤，或统一升级到支持正则的数据库版本。
关键点在于：别为了“看起来通用”牺牲可维护性；明确你的目标数据库版本，选最直接有效的方案。SQL Server 就用 PATINDEX，MySQL 8.0+ 就用 REGEXP，PostgreSQL 就用 ~——混用或降级方案反而更容易出错。
