sql中like的%和\_默认分别匹配零个或多个任意字符和任意单个字符；当数据中包含这些字符需作为字面值查询时，应使用escape关键字指定转义字符，如select productname from products where productname like '产品\\_a' escape '\'，其中反斜杠\为转义字符，使\_被视为普通下划线；选择转义字符时应确保其不在数据中出现，常用\、!或#；此外，精确匹配可用=，复杂模式可用正则表达式，子串查找可用instr等函数，方法选择需根据具体需求和数据特性决定。
在SQL中，当我们使用
LIKE进行模式匹配时，
%和
_是特殊的通配符，它们分别代表零个或多个字符以及任意单个字符。但如果我们的数据本身就包含这些字符，并且我们想把它们当作普通字符来查询，而不是通配符，这时候就需要
ESCAPE关键字来指定一个转义字符。它告诉数据库，紧跟在转义字符后面的
%或
_应该被视为字面意义上的字符，而不是通配符。
解决方案
LIKE操作符配合
ESCAPE关键字是处理SQL中特殊字符查询的直接方法。它的基本语法是：
SELECT column_name FROM table_name WHERE column_name LIKE 'pattern' ESCAPE 'escape_character';
这里的
pattern是你想要匹配的字符串，其中包含了需要被转义的
%或
_。
escape_character是你选择的任何一个字符，它在
pattern中用来标识其后的
%或
_是字面字符。
举个例子，假设我们有一个产品名称表，其中有些产品名包含
_或
%，比如
产品_A或
10%折扣。如果我想精确查找名为
产品_A的产品，而不是所有以
产品开头后面跟任意一个字符的产品，我就会这么做：
-- 查找产品名称中包含字面意义上的 '%' 的记录 SELECT ProductName FROM Products WHERE ProductName LIKE '%10\%%' ESCAPE '\'; -- 查找产品名称中包含字面意义上的 '_' 的记录 SELECT ProductName FROM Products WHERE ProductName LIKE '产品\_A' ESCAPE '\';
在这个例子中，我选择了反斜杠
\作为转义字符。当你看到
\%或
\_时，SQL就知道你想要匹配的是字符
%或
_本身，而不是它们的通配符含义。选择一个在你的数据中极少出现或根本不会出现的字符作为转义字符，这很重要。我个人比较倾向于
\，因为它在很多编程语言中也是常见的转义符，感觉更自然。
SQL LIKE中通配符%
和_
的默认行为是什么？
说到
LIKE，我记得刚开始接触SQL的时候，对
%和
_的理解还挺模糊的。默认情况下，
%是一个非常“贪婪”的家伙，它能匹配任意长度的字符序列，包括空字符串。比如
'A%'能匹配
'Apple'、
'Ant'，甚至只是
'A'。而
_则相对“专一”，它只匹配任意单个字符。
'A_C'会匹配
'ABC'、
'ADC'，但不会匹配
'AC'或
'ABBC'。
这种默认行为在进行模糊查询时非常方便，比如查找所有以“张”开头的姓名，
LIKE '张%'就搞定了。但问题就出在这里：如果我的数据本身就包含了这些符号，比如一个文件名叫做
report_final.pdf，而我只想精确地找到它，而不是所有
report开头后面跟一个字符的文件，那
LIKE 'report_final.pdf'（没有转义）就可能匹配不到，或者
LIKE 'report_%.pdf'会匹配到很多不相关的，因为它会把
_当作通配符。这种时候，我就会开始挠头，思考怎么才能告诉数据库，这个
_它就是个下划线，不是什么通配符。这就是
ESCAPE出场的背景，它给了我们一个明确的信号，把通配符“去通配符化”。
如何选择合适的ESCAPE
转义字符？
选择
ESCAPE字符，说实话，这事儿看似简单，但真要用起来，还是得稍微琢磨一下。最核心的原则就是：你选的这个字符，一定不能在你想要查询的字符串本身中出现。否则，你试图转义的那个
%或
_，可能会因为你的转义字符本身在数据中出现而产生歧义，导致查询结果不偏不倚地出错。
常用的转义字符有几个：
-
反斜杠
\
： 这是我最常用的，因为它在很多编程语言里都是默认的转义符，用起来有种“理所当然”的感觉。比如WHERE column LIKE 'test\\_data' ESCAPE '\'
。 -
感叹号
!
： 也是一个不错的选择，因为它通常不会出现在普通文本数据中。WHERE column LIKE 'test!%data' ESCAPE '!'
。 -
井号
#
： 同样是一个相对安全的字符。WHERE column LIKE 'test#%%data' ESCAPE '#'
。
有时候我会想，如果我的数据特别“野”，什么字符都可能出现，那怎么办？其实这种情况比较少见，大多数时候，我们都能找到一个相对安全的字符。如果真的非常极端，或者你需要处理的数据源非常多样化，那么你可能需要更复杂的逻辑，比如在应用层对查询字符串进行预处理，或者干脆考虑使用正则表达式（如果你的数据库支持）。但就
LIKE和
ESCAPE的场景而言，选一个你确信不会在数据中出现的简单字符，是最高效且最不容易出错的做法。
除了LIKE
和ESCAPE
，还有哪些处理特殊字符查询的方法？
当然，
LIKE和
ESCAPE虽然好用，但它们并非处理所有特殊字符查询的唯一或最佳方案。在某些场景下，我们会有其他的选择，甚至更强大的工具。
首先，最直接的，如果你需要精确匹配一个包含
%或
_的字符串，而不需要任何通配符功能，那么直接使用等号
=才是最简单粗暴且高效的。比如，要找产品名就是
10%折扣的记录，直接
WHERE ProductName = '10%折扣'，根本不需要考虑
LIKE和
ESCAPE。这种方式最直接，性能也最好，因为它不需要进行模式匹配的复杂计算。
其次，对于更复杂的模式匹配需求，尤其是涉及多种字符集、字符类别或者更灵活的重复次数匹配时，正则表达式（
REGEXP或
RLIKE，不同数据库系统可能名称不同，如PostgreSQL的
~操作符，MySQL的
REGEXP，Oracle的
REGEXP_LIKE）是极其强大的工具。正则表达式有自己一套完整的转义规则，通常也是使用反斜杠
\来转义特殊字符。例如，在MySQL中，如果你想查找包含字面意义上的
.字符的字符串，你会写成
WHERE column REGEXP '\\.'。这里需要两个反斜杠，因为SQL字符串本身也可能需要转义。正则表达式的优势在于其表达能力远超
LIKE，可以处理非常复杂的文本模式，但学习曲线相对陡峭，性能上可能也不如简单的
LIKE查询。
最后，如果你的目标仅仅是检查一个字符串是否包含另一个子字符串（而不是模式匹配），并且你确定子字符串中不会有
%或
_的通配符含义，那么使用
POSITION、
INSTR或
CHARINDEX这类函数（取决于你的数据库系统）也是一种选择。这些函数返回子字符串在主字符串中的起始位置。例如，
WHERE INSTR(ProductName, '10%折扣') > 0会查找
ProductName中是否包含
10%折扣这个子串。它们的语义更偏向于“查找子串”，而不是“模式匹配”，在某些特定场景下，语义更清晰，也可能因为内部实现的原因而更高效。
总的来说，
LIKE和
ESCAPE是处理SQL中通配符自身查询的“专业对口”工具，简单直观。但如果需求超出其能力范围，或者有更精确的匹配需求，那么
=、正则表达式或子串查找函数就成了更合适的选择。选择哪种方法，最终还是取决于具体的查询需求和数据特性。
