PATINDEX不支持真正正则匹配，仅识别%、_、[abc]、1等有限通配符；SQL Server 2025前无原生REGEXP支持，[0-9]仅为字符范围语法，不支持量词、分组等正则特性。xyz ↩
PATINDEX 不是正则引擎，它只支持有限通配符
直接说结论：PATINDEX 不能执行真正意义上的正则匹配，它只识别 %（任意长度字符串）、_（单个字符）、[abc]（字符类）、[^xyz]（否定字符类）这几种模式。所谓「正则模式」是误传——SQL Server 在 2025 版本前压根没有原生 REGEXP 支持。
常见误解是把 [0-9] 当成正则里的 \d，其实它只是 SQL 的字符范围语法，不支持量词（如 +、{2,}）、分组、断言、贪婪控制等任何正则特性。
-
PATINDEX('%[0-9]%', col)：查含至少一个数字的记录（正确） -
PATINDEX('[0-9]%', col)：只匹配「以单个数字开头」的值（漏了开头的%，逻辑错误） -
PATINDEX('%[0-9]{2}%', col)：语法报错，{2}不被识别 -
PATINDEX('%\d%', col)：直接失败，\d不是 PATINDEX 的合法语法
用 PATINDEX 实现常见「类正则」需求的写法
虽然不能写正则，但多数简单文本判断仍可用 PATINDEX 组合完成，关键在通配符位置和字符类设计：
- 查「含至少一个字母」：
PATINDEX('%[a-zA-Z]%', col) > 0 - 查「以字母开头、后跟数字」：
PATINDEX('[a-zA-Z][0-9]%', col) > 0（注意没开头%，强制开头匹配） - 查「含连续两位数字」：
PATINDEX('%[0-9][0-9]%', col) > 0（两个[0-9]并列） - 查「不含字母」（即纯数字或符号）：
PATINDEX('%[^a-zA-Z]%', col) > 0 AND PATINDEX('%[a-zA-Z]%', col) = 0（需双重判断） - 大小写敏感问题：若列排序规则是
_CS（Case-Sensitive），PATINDEX('%a%', col)不会匹配A；稳妥做法是统一转大写：PATINDEX('%[A-Z]%', UPPER(col)) > 0
SQL Server 2025+ 可用 REGEXP_* 函数替代 PATINDEX
如果你用的是 SQL Server 2025 或 Azure SQL 托管实例（Always-up-to-date），可以直接用标准正则函数，比如：
- 查含数字：
REGEXP_LIKE(col, '[0-9]') - 查以数字开头：
REGEXP_LIKE(col, '^[0-9]') - 提取第一个时间片段：
REGEXP_SUBSTR(col, '[0-9]{2}:[0-9]{2}') - 注意：
REGEXP_LIKE返回布尔值，不能直接和>比较；而PATINDEX返回位置整数，习惯写> 0判断存在性 - 性能差异明显：
REGEXP_LIKE在大数据量下通常比多个PATINDEX更快，但两者都难走索引
容易踩的坑：通配符、排序规则与性能
实际写错最多的地方不是逻辑，而是细节失控：
- 漏写两端的
%：写成PATINDEX('[0-9]', col)等价于col = '5'（只匹配单字符且完全相等） - 混淆字符类和通配符：
[0-9]是字符类，%是通配符，二者作用完全不同，不能互相替代 - 排序规则影响结果：
PATINDEX('%ä%', col)在Latin1_General_CI_AS下可能匹配a，但在SQL_Latin1_General_CP1_CS_AS下严格区分 - 无法优化：无论你加不加索引，
PATINDEX('%pattern%', col)都是全表扫描；真要高频查询，得建计算列 + 索引，例如ALTER TABLE t ADD has_digit AS CASE WHEN PATINDEX('%[0-9]%', col) > 0 THEN 1 ELSE 0 END PERSISTED
真正复杂的模式判断（比如邮箱、身份证、URL）别硬扛 PATINDEX，要么升级到 2025+ 用 REGEXP_LIKE，要么在应用层处理——数据库不是正则引擎。
