patindex在sql中用于查找模式在字符串中的起始位置，返回整数结果。其语法为patindex('%pattern%', expression)，支持通配符匹配，如%、\_、[]等。与like不同，like用于判断字符串是否符合模式并筛选数据，而patindex用于定位模式的具体位置。应用场景包括数据清洗和验证，如查找电话号码中的非数字字符或初步验证邮箱格式。使用时需注意特殊字符转义、性能影响及大小写敏感性问题。常见技巧包括组合通配符构建复杂模式，以及利用反向查找识别异常数据。
PATINDEX在SQL中是一个非常实用的字符串函数，它主要用于查找某个模式在指定字符串中首次出现的起始位置。简单来说，它告诉你一个你感兴趣的字符组合（模式）从哪儿开始。如果找不到，它就返回0。
PATINDEX的用法其实挺直观的，它的基本语法是 PATINDEX('%pattern%', expression)。这里的%pattern%就是你要查找的模式，而expression则是你要在其中搜索的字符串。值得注意的是，pattern里是支持通配符的，比如百分号%（匹配任意长度的任意字符）、下划线_（匹配单个任意字符）、方括号[]（匹配方括号内指定范围或列表中的任意单个字符），以及[^]（匹配不在方括号内指定范围或列表中的任意单个字符）。
举个例子，如果你想知道一个邮箱地址里“@”符号的位置，你可以这么写：SELECT PATINDEX('%@%', 'test@example.com')，结果会是5。但如果你想找“com”在URL里的位置，SELECT PATINDEX('%com%', 'www.example.com/index.html')，结果就是13。这东西的强大之处在于它的模式匹配能力，不仅仅是简单的字符串查找。我个人在处理一些不规范数据时，经常会用它来定位一些关键信息或者异常字符。
PATINDEX与LIKE有什么区别？何时选择PATINDEX？
说实话，很多人一开始都会把PATINDEX和LIKE搞混，甚至觉得它们是不是差不多的东西。但实际上，它们的用途和侧重点是完全不同的。
LIKE是一个逻辑运算符，它的核心功能是进行模式匹配的布尔判断。也就是说，你用LIKE，结果只会是“是”或“否”——你的字符串是不是符合某个模式。比如，SELECT * FROM Users WHERE Email LIKE '%@%.com'，它只会告诉你哪些用户的邮箱符合这种模式，而不会告诉你“@”或者“.com”具体在哪儿。它的目的是筛选数据，过滤出符合特定模式的记录。我经常把它看作是一个“过滤器”。
而PATINDEX呢，它是一个函数，它的返回结果是一个整数，代表了模式匹配的起始位置。它不是用来筛选记录的，而是用来“定位”的。你可能想知道某个特定字符集在哪一行字符串里出现，或者某个格式错误是从哪个位置开始的。比如，我曾经遇到一个需求，需要找出所有电话号码中包含非数字字符的记录，并且需要知道这些非数字字符第一次出现在哪里，以便进行清洗。这时候，PATINDEX('%[^0-9]%', PhoneNumber)就派上用场了。它会返回第一个非数字字符的位置，如果都是数字，就返回0。
所以，何时选择PATINDEX？当你需要知道“模式在字符串的哪个位置”时，选它。当你只需要知道“字符串是否符合某个模式”时，用LIKE。它们是互补的，而不是替代品。
PATINDEX在复杂模式匹配中的应用技巧与常见陷阱
PATINDEX在处理复杂模式时确实能展现出它的威力，但同时也伴随着一些小“坑”。
首先是模式的组合使用。你可以把各种通配符组合起来，构建出非常精细的匹配规则。比如，我想找出所有以字母开头，后面跟着至少一个数字，再跟着任意字符的字符串，这可能有点复杂，但PATINDEX可以做到。PATINDEX('[A-Z]%[0-9]%', YourColumn)。这里的关键是理解通配符的优先级和作用范围。[A-Z]匹配单个大写字母，%匹配任意字符，[0-9]匹配单个数字。
Perl 基础入门中文教程，chm格式，讲述PERL概述、简单变量、操作符、列表和数组变量、文件读写、模式匹配、控制结构、子程序、关联数组/哈希表、格式化输出、文件系统、引用、面向对象、包和模块等知识点。适合初学者阅读和了解Perl脚本语言。
一个常见的陷阱是关于模式中特殊字符的处理。如果你要查找的模式本身就包含通配符（比如%或_），你就需要使用ESCAPE子句来转义它们。例如，如果你想查找字符串中字面意义上的_，你需要这么写：PATINDEX('%[_]%', YourStringColumn ESCAPE '\')。这里\就是转义字符。我个人就曾因为忘记转义而浪费了不少时间调试，以为是模式写错了。
另一个需要注意的点是性能。PATINDEX涉及到字符串的扫描，如果在大表上对非索引列进行复杂的PATINDEX操作，可能会导致性能问题。尤其是在模式非常复杂或者字符串非常长的情况下，数据库引擎需要做更多的工作。所以，在生产环境中，我通常会建议先在小数据集上测试性能，或者考虑是否可以通过其他方式（比如预处理、ETL阶段清洗）来避免在查询时频繁使用它。
最后，记得PATINDEX是大小写敏感的，这取决于你的数据库排序规则（Collation）。如果你的排序规则是大小写不敏感的，那么PATINDEX也会表现出大小写不敏感的特性。但如果你需要严格的大小写匹配，你可能需要在使用PATINDEX时显式地指定一个大小写敏感的排序规则。
如何利用PATINDEX进行数据清洗与验证？
PATINDEX在数据清洗和验证方面简直是利器。我经常用它来找出那些“不合规”的数据，然后进行修正。
一个最常见的场景就是数据格式验证。比如，你有一个存储电话号码的列，但你发现里面混入了一些非数字字符。你可以用PATINDEX('%[^0-9]%', PhoneNumberColumn)来找出所有包含非数字字符的记录。返回0的说明是纯数字，非0的就说明有问题，而且这个非0的值还告诉你问题出在哪儿。这样，你就可以针对性地去清理这些数据，比如使用REPLACE函数将这些非法字符替换掉，或者直接标记出来进行人工核查。
再比如，邮箱地址的简单验证。虽然正则表达式更强大，但对于一些基本的校验，PATINDEX也能胜任。你可以检查邮箱是否包含@符号，以及@后面是否跟着至少一个点（.）。PATINDEX('%@%.%', EmailColumn)可以初步筛选出一些明显不符合邮箱格式的记录。当然，这只是一个非常粗略的验证，真正的邮箱验证需要更复杂的逻辑。
我个人还会用PATINDEX来识别一些“垃圾数据”或者“噪音”。比如，用户在文本输入框里不小心输入了一些特殊符号，或者一些广告信息。通过构建包含这些特殊符号或关键词的模式，我可以用PATINDEX快速定位这些记录。比如，PATINDEX('%[~!@#$%^&*()]%', CommentColumn)可以找出包含常见特殊符号的评论。
利用PATINDEX进行数据验证时，一个重要的思想是“反向查找”：与其去匹配所有正确的格式，不如去查找所有错误的模式。当PATINDEX返回非零值时，就说明你的数据存在潜在问题，需要进一步处理。这比逐一检查每个字符是否符合要求要高效得多。它提供了一个快速、直接的方式来发现数据中的“异类”。
