提到SQL Server中几个常用的字符串函数，PATINDEX算一个比较特殊的存在——它的核心价值在于按模式匹配去定位文本位置，但许多刚接触的人往往栽在它的“小脾气”上。先划个重点：它只在SQL Server和Azure SQL里能用，MySQL、PostgreSQL、SQLite这些数据库千万别碰，否则会直接报语法错误或提示“Invalid column name 'PATINDEX'”。
用法：PATINDEX的模式写法和通配符规则
PATINDEX不是正则引擎，它用的还是SQL Server那套LIKE风格的通配符：%（匹配任意长度）、_（单个字符）、[abc]（字符集里的一个）、[^0-9]（排除数字）等等。但有个容易踩的坑：模式必须以%开头，否则它永远匹配失败——哪怕你只是想找开头的子串。
举几个常见错误：PATINDEX('abc%', @text)永远返回0，因为缺少前导%。正确写法是PATINDEX('%abc%', @text)。同理，想找到第一个数字位置，用PATINDEX('%[0-9]%', @text)；如果想定位“Error:”开头的片段，也得写成PATINDEX('%Error:%', @text)（前后都带%）。
- 区分大小写的情况：这取决于数据库排序规则。如果数据库是
SQL_Latin1_General_CP1_CS_AS，那它就区分；否则默认不敏感。需要强制时，可以拼接COLLATE指定排序规则。
PATINDEX返回值含义与空值处理
这个函数的返回值是从1开始计数的位置索引（不是0），找不到时返回0——但注意，不是返回NULL。所以千万别用IS NULL去判断是否匹配成功，那是永远为真的。
典型的误用场景：WHERE PATINDEX('%d%', col) IS NOT NULL——这个条件永远为真，因为返回0而不是NULL。正确做法是WHERE PATINDEX('%[0-9]%', col) > 0。
- 结果为0表示未匹配，千万不要想成“第0位”
- 如果字段本身是
NULL，那PATINDEX也直接返回NULL，不是0——所以建议先做IS NOT NULL过滤或用ISNULL(PATINDEX(...), 0)处理 - 对
TEXT类型字段的使用也要注意：SQL Server 2016+已弃用TEXT类型，建议全部转为VARCHAR(MAX)再操作
替代方案：跨数据库兼容性问题怎么绕开？
如果项目需要兼容多个数据库，PATINDEX这条路基本上走不通。PostgreSQL可以用POSITION('pattern' IN col)（仅支持字面匹配）或REGEXP_MATCHES；MySQL 8.0+用REGEXP_INSTR(col, 'pattern')；SQLite干脆没有内置的等效函数，只能在应用层自己处理。
面对多数据库兼容的需求，一个务实做法是：别死磕模式搜索，用标准函数做简单子串定位。SQL Server里可以换用更快的CHARINDEX，MySQL和PostgreSQL则用INSTR。复杂模式识别交给应用层代码去解析，这样更可控。
- 在SQL Server内部，
CHARINDEX('abc', col)比PATINDEX快不少，但它不支持通配符 - 性能上
PATINDEX明显低于CHARINDEX，尤其在处理大文本和复杂模式时。建议慎用于WHERE条件中的高频列 - 没有
NOT PATINDEX这种语法，否定逻辑只能通过PATINDEX(...) = 0来写
最后提醒一句：真正容易被忽略的是排序规则的影响。同一个模式在Latin1_General_CI_AS（不区分大小写）和Latin1_General_CS_AS（区分大小写）下，返回的位置可能完全不同，特别是涉及大小写或重音字符时。上线前必须在你目标的数据库环境下实际测试一遍。
