PATINDEX在SQL Server中仅支持简单通配符，不支持正则量词、捕获组等复杂特性；MySQL 8.0+需用REGEXP_INSTR定位匹配位置；PostgreSQL依赖SUBSTRING或regexp_matches间接计算；跨库复杂模式应交由应用层处理。
PATINDEX 在 SQL Server 中匹配复杂模式的实际限制
SQL Server 的 PATINDEX 不支持正则表达式，只支持有限的通配符模式（%、_、[abc]、[^a-z]），无法处理捕获组、量词（如 +、{2,5}）、断言或非贪婪匹配。所谓“复杂模式”一旦涉及重复结构、可选片段或边界条件，PATINDEX 就会失效。
常见错误现象：PATINDEX('%[0-9]{3}[-][0-9]{2}[-][0-9]{4}%', @str) 看似想匹配社保号格式，但 {3} 不被识别——实际会被当作字面量花括号处理，导致永远返回 0。
- 真正能用的模式仅限于类似
'%[0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9][0-9][0-9]%'这种展开写法 - 无法区分单词边界，
PATINDEX('%cat%', 'scatter')会误命中 - 不支持忽略大小写以外的标志（如全局匹配、多行模式），行为完全依赖数据库排序规则
MySQL 8.0+ 的 REGEXP_SUBSTR 和位置提取技巧
MySQL 8.0 起支持真正的正则引擎，但注意：原生 REGEXP 操作符只返回布尔值；要定位位置，必须用 REGEXP_SUBSTR 配合 CHAR_LENGTH 和子串计算，或借助 REGEXP_INSTR（MySQL 8.0.4+）。
例如定位第一个符合邮箱格式的子串起始位置：
SELECT REGEXP_INSTR('Contact: admin@example.com or help@site.co', '[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}') AS pos;
关键细节：
-
REGEXP_INSTR默认从第 1 个字符开始，第 3 个参数是出现序号（1=首次），第 4 个是匹配位置偏移（通常为 1） - 反斜杠需双写（
\.），否则.被当通配符 - MySQL 正则不支持
\d，必须写[0-9]；也不支持\b单词边界，可用(^|[^A-Za-z0-9])模拟 - 性能敏感场景慎用：正则匹配无法使用索引，全表扫描开销明显
PostgreSQL 中使用 POSIX 正则 + SUBSTRING 定位子串
PostgreSQL 不提供直接返回位置的正则函数，但 SUBSTRING 支持正则捕获，并可配合 POSITION 或字符串截取间接推算位置。
更可靠的做法是用 REGEXP_MATCHES（返回匹配数组）结合 generate_subscripts，但最简实用方案是：
SELECT LENGTH(SUBSTRING('ID: ABC123, ref: XYZ789' FROM '^[^A-Z]*')) + 1
AS start_pos;
这利用了 SUBSTRING 的正则提取能力，先取“开头非大写字母部分”，再算其长度加 1 得到首个大写字母位置。不过此法有局限：
- 只能定位“开头满足某条件”的片段，通用性差
- 真正需要精确起始/结束偏移时，得用
regexp_matches配合pg_catalog.regexp_matches的g标志和数组下标，代码冗长 - POSIX 正则语法与 PCRE 不同：不支持
\K、不支持命名捕获组，?量词需写成{0,1}
跨数据库的务实建议：什么情况下该放弃 SQL 内置正则
当模式包含嵌套括号、递归结构、上下文相关匹配（如“匹配引号内但排除转义引号”），或需多次迭代提取时，SQL 的正则能力基本不可靠。
这时应把数据拉到应用层处理：
- SQL Server：用 CLR 集成 .NET 的
Regex类（需启用TRUSTWORTHY，生产环境常被禁用） - MySQL / PostgreSQL：在 Python/Go 中批量处理，用
re.finditer或regexp.FindAllStringIndex获取精准坐标，再回写结果 - ETL 场景下，优先考虑在 Spark 或 Flink 中用完整正则引擎预处理，而非强求 SQL 完成
最容易被忽略的一点：即使语法正确，不同数据库对 Unicode 字符（如中文、emoji）的正则支持差异极大——MySQL 默认按字节匹配，PostgreSQL 依赖 LC_CTYPE，SQL Server 的排序规则决定是否识别宽字符。没在目标环境实测过，就别信文档里的“支持 Unicode”。
