# PATINDEX 与 LIKE 对比：为什么模糊定位首选 PATINDEX？ 在 SQL Server 的字符串处理中，`PATINDEX` 函数因其能够返回匹配模式的精确位置（从 1 开始计数），而比仅能进行布尔判断的 `LIKE` 运算符更适合模糊定位场景。当你需要明确“特定模式出现在字符串的第几个字符”，或者需要结合 `SUBSTRING` 函数截取后续内容时，`PATINDEX` 往往是唯一高效的选择。 一个常见的误用是将 `PATINDEX` 当作 `LIKE` 的简单替代品，仅在 `WHERE` 子句中判断返回值是否大于 0。这种做法不仅无法发挥其性能优势，还完全丧失了精准定位的能力。 * `PATINDEX('%box%', product_name)` 返回 5，表明 “box” 从字符串的第 5 位开始出现。 * `PATINDEX('Hello%', 'Hello World')` 返回 1，因为模式匹配从字符串开头起始。 * `PATINDEX('%end', 'no end')` 返回 4，模式尾部的 `%` 表示“以 end 结尾”。 * 若未找到匹配项，函数返回 `0`；若 `pattern` 参数为 `NULL`，则返回 `NULL`；若 `expression` 参数为 `NULL`，则会直接报错。 ## 通配符使用规范：必须显式添加 %，否则行为与预期不符 许多开发者误写 `PATINDEX('abc', col)` 来查找包含 “abc” 的字段，结果全部返回 0。这是因为 `PATINDEX` 不会自动补全通配符 `%`，必须由用户显式写出。 规则很清晰：`%` 代表零个或多个任意字符，`_` 代表一个任意字符。但需注意：`%` 必须出现在模式字符串的两端（或至少一端），除非你明确要查询开头或结尾的匹配。 * 查找中间包含 “202[0-9]” 的文本：使用 `PATINDEX('%202[0-9]%', text)`。 * 查找以数字开头的文本：使用 `PATINDEX('[0-9]%', text)`（开头无需 `%`）。 * 查找以 “.pdf” 结尾的文本：使用 `PATINDEX('%.pdf', text)`（结尾无需 `%`）。 * 错误示例：`PATINDEX('202[0-9]', text)` —— 这只会匹配整个字符串恰好等于该模式的情况，几乎总是返回 0。 ## 处理长文本（varchar(max)/nvarchar(max)）时的返回类型注意事项 当 `expression` 参数是 `varchar(max)` 或 `nvarchar(max)` 类型时，`PATINDEX` 的返回类型是 `bigint`；否则返回 `int`。如果忽略这一点，在大文本中匹配到靠后的位置（例如第 300 万个字符）时，用 `int` 类型的变量接收会导致溢出，结果可能变为负数或被截断。 实际编码中，建议统一使用 `CAST(PATINDEX(...) AS bigint)` 进行显式转换，尤其是在与 `SUBSTRING` 函数配合使用时： ```sql SELECT SUBSTRING(long_text, CAST(PATINDEX('%start%', long_text) AS bigint) + 6, 100) AS extracted FROM docs ``` 此外，`PATINDEX` 对数据库的排序规则敏感。如果字段的排序规则是 Latin1_General_BIN（二进制），而你按照常规的大小写不敏感方式编写模式，可能会导致匹配失败。必要时，可通过 `COLLATE SQL_Latin1_General_CP1_CI_AS` 显式指定排序规则。 ## 在 LINQ to Entities 中无法直接调用 SqlFunctions.PatIndex 如果你在使用 EF6 编写 C# 查询，看到 `SqlFunctions.PatIndex` 方法就想直接调用，可能会遇到运行时错误：`Method 'PatIndex' is not supported`。这是因为该方法只能出现在查询表达式树中，不能作为普通的 .NET 方法调用。 正确的使用方式是将它嵌入到 `Where` 或 `Select` 的 Lambda 表达式中： ```csharp ctx.Products.Where(p => SqlFunctions.PatIndex("%box%", p.Name) > 0) ``` EF Core 不再支持 `SqlFunctions` 类，需改用 `EF.Functions.Like` 或原始 SQL 语句。而 `PATINDEX` 的定位能力在 EF Core 中没有等效的封装，真要使用就必须通过 `FromSqlRaw` 编写原始 SQL。 一个容易被忽略的要点是：SQL Server 2025（17.x）已开始支持原生正则函数，如 `REGEXP_LIKE`。但截至 2026 年 4 月，该功能仍处于预览阶段，生产环境需谨慎使用。相比之下，`PATINDEX` 虽是一项较老的技术，却是当前最稳定可靠的通配符定位解决方案。