MySQL中需用ESCAPE子句转义LIKE的_和%，如WHERE name LIKE 'user_%' ESCAPE ''；REGEXP可避免转义但不走索引，结构化匹配选REGEXP，简单字面匹配优先LIKE ESCAPE。
MySQL LIKE 查询下划线和百分号怎么不被当通配符？
在MySQL里，下划线 _ 和百分号 % 在 LIKE 操作符中天生就是通配符。这就带来一个实际问题：当你真想查找字段里包含这两个字符本身时，比如用户名是 user_2024，或者路径像 /home/%backup/，该怎么办？答案很明确：必须进行显式转义。MySQL在这点上比较“固执”，它不会像PostgreSQL那样默认把反斜杠当作转义符，所以你得手动通过 ESCAPE 子句来告诉它。
一个典型的错误示范是直接写 WHERE name LIKE 'user_%'。猜猜结果会怎样？它会匹配到所有以“user”开头、后面跟着任意单个字符的记录，比如 user_a、user123，这完全偏离了查找字面下划线的初衷。
- 如果你选择用反斜杠
作为转义符，那么必须在LIKE后面明确加上ESCAPE ''。完整的写法应该是：WHERE name LIKE 'user_%' ESCAPE ''。 - 情况如果更复杂一点，假设字段里存的就是带反斜杠的文本，比如
user\_test，那么查询条件就得写成LIKE 'user\\_%' ESCAPE '\'。这里涉及两层解析：SQL语句本身先解析一次反斜杠，然后LIKE引擎再进行一次解析。 - 选择转义符也有讲究。尽量避免使用像
/或#这类本身可能在数据中间出现的字符，否则容易引起混淆。一个稳妥的建议是，固定使用反斜杠，并在所有相关查询中统一声明ESCAPE。
REGEXP 能否替代 LIKE 处理特殊字符？
当然可以。REGEXP（或者它的同义词 RLIKE）天生就把 _ 和 % 视为普通字符，不需要额外转义。但是，这里有个关键区别需要注意：REGEXP 默认进行的是**多字符匹配**。也就是说，只要字段值的任何部分符合正则表达式，就算匹配成功。这不像 LIKE，默认是进行整个字段的匹配（除非你主动加上 % 通配符）。
举个例子就明白了：name REGEXP '_test' 会匹配到 abc_test、test_xxx 所有包含“_test”子串的记录。而 name LIKE '_test' 则严格得多，它只匹配长度为5个字符、且第2到第5个字符是“test”的值，因为这里的 _ 被解释为匹配任意单个字符的通配符。
- 如果你想用
REGEXP实现全字段精确匹配，必须使用锚点：name REGEXP '^user_test$'。注意，这里的_就是字面意义上的下划线，但在MySQL的正则引擎里，它本身不需要转义。 - 关于大小写敏感性，
REGEXP的行为取决于字段的排序规则（collation）。如果需要忽略大小写，可以显式指定一个不区分大小写的collation，例如COLLATE utf8mb4_0900_as_cs，或者直接使用REGEXP BINARY。 - 性能方面是个重要考量。
REGEXP通常无法利用索引（除了MySQL 8.0及以上版本中极少数函数索引的场景）。因此，在数据量大的表上，它的速度可能比使用前缀匹配的LIKE 'prefix%'慢很多。
实际场景中该选 LIKE ESCAPE 还是 REGEXP？
选择的核心依据，在于你的匹配模式是否“结构化”。所谓结构化，就是是否有明确的模式规则。
如果只是查找一个固定的模式，比如“log_”后面跟上具体的年月（log_202404），那么 LIKE 通常更快、写法也更直观。但如果你的需求是查找“下划线后必须紧跟4位数字”，或者“以斜杠开头、且包含以.conf结尾的路径”这类带有规则约束的情况，那么 REGEXP 就更得心应手了。
- 简单字面匹配：如果你的目标仅仅是查找包含
_或%这些字符本身的记录，优先考虑LIKE ... ESCAPE。只要模式以常量开头，它还有可能利用索引进行前缀扫描，效率更高。 - 复杂规则匹配：如果需要用到字符类（如
[a-z]）、重复次数（如{4}）、位置锚点（如^和$）等，例如^[a-z]+_[0-9]{4}$，那就必须使用REGEXP。 - 处理含大量反斜杠的数据：当字段值本身包含很多反斜杠时（比如典型的Windows路径
C:Usersest ile.txt），使用ESCAPE的写法会变得非常容易出错。这时更建议改用REGEXP，并在正则表达式中用双反斜杠进行转义，例如：path REGEXP 'C:\\Users\\test'。
为什么有时 ESCAPE 后还是查不到数据？
这个问题常常让人困惑。语法明明没错，为什么就是查不到？很多时候，坑并不在语法本身，而是藏在字符集和排序规则（collation）导致的隐式转换里。
想象一下这个场景：你的表字段定义为 VARCHAR(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci，查询时也写了 ESCAPE ''。但问题出在，客户端连接的字符集可能是 latin1。这样一来，你发送的反斜杠在传输过程中就可能被截断或解释成乱码，导致转义彻底失效。
- 首先，可以执行
SELECT @@character_set_client, @@collation_connection;来确认连接层的编码设置是否与表结构一致。 - 做一个快速测试：运行
SELECT 'a_b' LIKE 'a_b' ESCAPE '';。如果转义生效，结果应该返回1（真）。如果返回0，那就明确说明ESCAPE没起作用，第一步就应该检查连接配置。 - 别忘了应用层框架的影响。某些ORM工具（例如旧版本的Django）会自动帮你处理
LIKE查询中的转义。如果你再手动拼接SQL并添加转义，就会造成重复转义，最终导致查询失败。遇到这种情况，正确的做法是关闭ORM的自动转义功能，或者改用参数化查询来规避这个问题。
说到底，MySQL的转义逻辑本身并不复杂。真正的挑战在于，如何在不同的字符集环境、不同的客户端工具以及不同的ORM框架之间，确保行为的一致性。因此，一个至关重要的建议是：在将查询部署上线之前，务必使用真实的数据和真实的连接方式，完整地跑一遍 EXPLAIN 查看执行计划，并仔细校验查询结果。这一步，能帮你避开大多数意想不到的麻烦。
