patindex不支持复杂正则模式，仅识别%、_、[abc]、1四种通配符；花括号、反斜杠、圆括号等均作字面量处理，无法实现量词、边界、分组等正则特性。xyz ↩
PATINDEX 根本不支持复杂正则模式
SQL Server 的 PATINDEX 不是正则引擎，它只认四种通配符：%（任意长字符串）、_（单个字符）、[abc]（字符集）、[^xyz]（非字符集）。所谓“复杂模式”——比如 [0-9]{3}-[0-9]{2}-[0-9]{4}、\bcat\b、(\d{4})-(\d{2})——全部无效。花括号 {}、反斜杠 \、圆括号 ()、问号 ?、加号 + 等，都会被当作字面量处理。
常见错误现象：
-
PATINDEX('%[0-9]{2}%', 'ID: A12B')永远返回 0 ——因为{2}不是通配语法，而是两个普通字符 -
PATINDEX('%cat%', 'scatter')返回 1，无法避免子串误匹配 -
PATINDEX('%[^a-z][A-Z]%', 'helloWorld')看似想找“小写后接大写”，但实际匹配的是“任意非小写字母 + 任一大写字母”，逻辑完全跑偏
能用 PATINDEX 的“复杂”其实只是通配展开
真正可落地的“稍复杂”匹配，必须手动展开所有可能性，靠通配符组合硬凑。比如匹配社保号格式 XXX-XX-XXXX（纯数字），只能写成：
PATINDEX('%[0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9][0-9][0-9]%', @str)
这不是正则，是穷举。要点：
- 每个
[0-9]占一位，不能省；[0-9][0-9]≠[0-9]{2} - 若允许前导空格或中间可选空格，得额外加
[ _]，如'%[0-9][0-9][0-9][ _]-[ _][0-9][0-9][ _]-[ _][0-9][0-9][0-9][0-9]%' - 无法表达“至少 2 位但不超过 4 位数字”，只能拆成多个
PATINDEX或用CASE组合判断 - 排序规则影响大小写行为：默认不区分大小写，如需区分，得显式用
COLLATE Latin1_General_BIN
替代方案：别硬扛，该上 CLR 或应用层就上
一旦模式涉及重复、边界、分组、可选段，PATINDEX 就该让位。可行路径有且仅有两条：
- 启用 SQL Server CLR 集成，注册 .NET 正则类（如
Regex.IsMatch），再封装为 T-SQL 函数——但需 DBA 开启TRUSTWORTHY或签名部署，生产环境常被禁用 - 把匹配逻辑移出数据库：在应用代码（C#、Python、Java）中用原生正则处理字符串，SQL 只负责取原始字段，避免全表扫描+CPU 密集型计算
- 用
LIKE做粗筛 + 应用层精筛：例如先WHERE col LIKE '%[0-9]%-[0-9]%-%'快速过滤，再由程序做正则校验
性能提醒：PATINDEX 无法走索引，任何带前导 % 的模式都触发全表/全索引扫描；越“复杂”的通配展开，CPU 消耗越高。
和 CHARINDEX 的关键区别别搞混
PATINDEX 和 CHARINDEX 都返回位置，但能力边界完全不同：
-
CHARINDEX('abc', col)：只找字面量'abc'，快、可部分走索引（取决于写法），不支持通配 -
PATINDEX('%ab_c%', col)：支持通配，但必须带%包裹，且无法利用索引优化 - 想查“以 abc 开头”，
CHARINDEX('abc', col) = 1比PATINDEX('abc%', col) = 1更高效、语义更清晰 - 两者都返回从 1 开始的位置，未匹配均返回 0 —— 判断时务必写
> 0，别漏掉等于 0 的情况
真正容易被忽略的点：PATINDEX 的模式参数必须是字符串字面量或变量，不能是表达式拼接结果（如 '%'+@prefix+'%' 在某些执行计划下会失效），且长度超 8000 字节时可能截断。
