在MySQL中，LIKE运算符用于实现模糊匹配，其中百分号表示任意长度的任意字符序列，下划线表示单个任意字符。这种设计在搜索前缀、后缀或固定模式时非常方便，但一旦业务数据本身包含百分号或下划线，查询就会偏离预期。例如商品名称可能叫“100%纯果汁”，文件路径可能包含“report_2024_final.docx”。如果不做特殊处理，WHERE name LIKE '100%纯果汁'会把所有以“100”开头的记录都查出来，而不只是“100%纯果汁”。ESCAPE关键字就是用来解决这个问题的，它能指定一个转义字符，让紧随其后的通配符按字面值参与比较。
一、ESCAPE的基础语法与转义机制
ESCAPE关键字不是独立存在的，它必须配合LIKE一起使用，语法结构为：expression LIKE pattern ESCAPE 'escape_char'。其中escape_char只能是一个字符，它告诉MySQL：在pattern中，凡是以这个字符为前缀的下一字符，都按照普通字符处理，不再承担通配符职责。换句话说，转义字符本身不会被计入匹配结果，它只是一个标记。
先看一个最简单的例子。假设products表中存在一条记录，name字段值为“100%纯果汁”，另有一条记录为“100纯果汁”。如果执行未转义的查询：
SELECT id, name FROM products WHERE name LIKE '100%纯果汁';
这条SQL会把“100%纯果汁”和“100纯果汁”都查出来，因为百分号被解释成了“任意长度字符”。要想只匹配百分号本身，可以使用ESCAPE指定一个转义符：
SELECT id, name FROM products WHERE name LIKE '100!%纯果汁' ESCAPE '!';
这里的!就是转义字符，它后面的百分号被当作普通字符，所以模式实际要求字符串依次包含“100”“%”“纯果汁”，查询结果就精确了。可以看到，转义机制的本质是在模式串中增加一个前置控制字符，让MySQL改变对后续字符的解析方式。
需要特别注意的是，转义字符只对它后面紧跟的单个字符生效。如果模式写成'100!%纯果汁!%'，那么第一个!%匹配字面百分号，第二个!%同样匹配字面百分号，二者互不干扰。如果转义字符后面没有其他字符，或者转义字符本身出现在模式末尾，不同MySQL版本的处理可能存在差异，实际开发中应避免让模式以转义字符结尾。
二、默认反斜杠与ESCAPE的配合关系
很多开发者习惯使用反斜杠作为转义字符，因为在MySQL字符串中，反斜杠本身就具备转义能力。但这里有一个容易混淆的地方：SQL字符串字面量解析和LIKE模式解析是两个不同阶段。假设要匹配“100%纯果汁”，如果直接写LIKE '100\%纯果汁'，MySQL会先把字符串中的\%解析成字面百分号，最终交给LIKE的模式仍是“100%纯果汁”，百分号依然被当作通配符，转义失效。
要让反斜杠真正进入LIKE模式，必须在SQL字符串中写两个反斜杠，即：
SELECT id, name FROM products WHERE name LIKE '100\\%纯果汁' ESCAPE '\\';
在这条SQL中，字符串字面量里的\\会被解析成一个实际反斜杠，最终LIKE接收到的模式为100\%纯果汁。ESCAPE'\\'又告诉MySQL这个反斜杠是转义字符，于是\%匹配字面百分号。整个过程经过了“字符串转义”和“模式转义”两层处理，这是很多查询结果不符合预期的根源。
与之相比，使用感叹号、竖线、@等很少出现在业务数据中的字符作为转义符，可以显著降低这种双层转义带来的心智负担。例如ESCAPE '!'只要求模式中出现!%，而!本身在SQL字符串中不需要额外转义，写法更直观。唯一的前提是确保选用的转义字符不会频繁出现在被匹配字段中，否则仍可能造成匹配错误。
三、为业务数据选择安全的转义字符
选择转义字符时，首先应分析目标字段的字符分布。如果你的数据包含大量反斜杠，例如Windows路径C:\Users\admin\report_2024.xlsx，还使用反斜杠作为ESCAPE转义符就会很痛苦，因为字符串中的每个反斜杠都要考虑是否需要成倍书写。此时改用!、#、@等符号更合适。
下面的SQL演示了使用感叹号转义下划线和百分号，匹配文件路径中的下划线字面值：
SELECT id, file_path FROM files WHERE file_path LIKE '%report!_2024.xlsx%' ESCAPE '!';
这段代码中，!_确保下划线不会匹配任意单个字符，而是精确匹配文件名中的下划线。如果路径里还包含百分号，可以继续使用!%来转义。
另外，ESCAPE子句指定的转义字符必须是单字符。MySQL允许使用多字节字符集中的字符，但在查询时需要保证客户端和连接字符集一致，否则可能出现截断或无法识别的情况。对于中文业务，通常不建议使用中文汉字作为转义符，因为一个汉字在UTF-8下占多个字节，虽然MySQL将其视为一个字符，但可读性和维护性较差。
四、动态构造LIKE模式时的转义顺序与函数封装
在实际应用中，模糊查询的搜索词往往来自用户输入。如果直接拼接用户输入进入LIKE模式，用户输入中的百分号和下划线仍会被当作通配符，导致查询结果过多。要解决这个问题，必须在应用层或数据库层对用户输入做转义处理，同时配合ESCAPE子句。
下面是一个MySQL存储函数的示例，它使用感叹号作为转义字符，对输入字符串中的感叹号、百分号和下划线依次进行转义：
DELIMITER $$
CREATE FUNCTION escape_like_pattern(input VARCHAR(255))
RETURNS VARCHAR(255)
BEGIN
SET input = REPLACE(input, '!', '!!');
SET input = REPLACE(input, '%', '!%');
SET input = REPLACE(input, '_', '!_');
RETURN input;
END$$
DELIMITER ;
这个函数先转义感叹号本身，再转义百分号和下划线，原因是如果先转义通配符，后续再转义感叹号可能重复处理已经生成的转义前缀。例如输入字符串是50_折扣!商品，经过函数处理后变成50!_折扣!!商品。查询时这样写：
SELECT id, name FROM products
WHERE name LIKE CONCAT('%', escape_like_pattern('50_折扣!商品'), '%') ESCAPE '!';
LIKE模式中的!_匹配字面下划线，!!匹配字面感叹号，两侧的百分号仍然保留通配含义，实现包含匹配。这个封装方式可以避免在业务代码中散落大量REPLACE调用，也降低了漏转义的风险。
如果更倾向于在应用层处理，也可以用类似思路封装一个方法。例如在Java中先对用户输入调用replace替换感叹号、百分号和下划线，再在SQL中固定使用ESCAPE '!'。关键是转义顺序不能颠倒：一定先处理转义字符本身，再处理百分号和下划线。否则一旦原始输入包含转义字符，后续生成的转义前缀可能再次被处理，导致模式错乱。
还有一种常见误区是以为参数绑定会自动处理LIKE通配符。实际上，JDBC、PDO等驱动只会对参数值做SQL注入转义，并不会识别LIKE语义。即使使用预编译语句，用户输入中的%和_依然会被MySQL当成通配符。因此，只要涉及用户输入进入LIKE模式，就必须在业务层或SQL层显式执行通配符转义，并配合ESCAPE关键字声明转义字符。
通过以上分析可以看到，ESCAPE关键字虽然语法简单，但在实际使用中必须同时关注字符串字面量解析、通配符位置、转义字符选择以及动态拼接顺序。只有把这些细节都考虑清楚，才能让模糊查询既保持灵活，又不会因为数据中的特殊字符而失控。
MySQL ESCAPELIKE通配符转义字符修改时间：2026-08-27 19:46:28