mysql中需用escape子句转义like的_和%，如where name like 'user_%' escape ''；regexp可避免转义但不走索引，结构化匹配选regexp，简单字面匹配优先like escape。
MySQL LIKE 查询下划线和百分号怎么不被当通配符？
下划线 _ 和百分号 % 在 LIKE 中默认是通配符，想查真实含这两个字符的字段（比如用户名 user_2024 或路径 /home/%backup/），必须显式转义。MySQL 不像 PostgreSQL 那样自动识别反斜杠为转义符，得手动指定 ESCAPE 子句。
常见错误是直接写 WHERE name LIKE 'user_%'——这会匹配 user_a、user123 等所有“user”后跟任意单字符的值，根本不是你想要的字面量下划线。
- 用
作转义符时，必须在LIKE后加ESCAPE ''，例如：WHERE name LIKE 'user_%' ESCAPE '' - 如果字段本身存的就是双反斜杠（如
user\_test），那得写成LIKE 'user\\_%' ESCAPE '\'——因为 SQL 字符串先解析一次反斜杠，再由 LIKE 引擎解析一次 - 避免用
/或#这类可能出现在数据中的字符做转义符，否则容易混淆；推荐固定用并统一 ESCAPE 声明
REGEXP 能否替代 LIKE 处理特殊字符？
REGEXP（或 RLIKE）天然把 _、% 当普通字符，不需要额外转义，但要注意它默认是**多字符匹配**：只要字段中某处符合正则即命中，不像 LIKE 默认是全字段匹配（除非你加了 %）。
比如 name REGEXP '_test' 会匹配 abc_test、test_xxx（只要含 _test 子串），而 name LIKE '_test' 只匹配 5 个字符、第 2–5 是 test 的值（因为 _ 是单字符通配符）。
- 要全字段精确匹配，得用锚点：
name REGEXP '^user_test$'（注意这里_是为了在正则里字面匹配下划线，MySQL 正则引擎要求对_转义） -
REGEXP对大小写敏感性取决于字段 collation；若需忽略大小写，用COLLATE utf8mb4_0900_as_cs显式指定或改用REGEXP BINARY - 性能上，
REGEXP无法利用索引（除极少数 MySQL 8.0+ 的函数索引场景），大数据量时比LIKE 'prefix%'慢得多
实际场景中该选 LIKE ESCAPE 还是 REGEXP？
核心看匹配模式是否「结构化」：如果只是查固定前缀+一个字面下划线（如 log_202404），LIKE 更快更直观；如果要查「下划线后跟 4 位数字」或「以 / 开头、含 .conf 结尾」这类规则，REGEXP 更合适。
- 简单字面匹配（含
_/%）→ 优先用LIKE ... ESCAPE，支持索引前缀扫描 - 需要字符类、重复次数、位置约束（如
^[a-z]+_[0-9]{4}$）→ 必须用REGEXP - 字段值本身含大量反斜杠（如 Windows 路径
C:Users est 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 的自动转义或改用参数化查询
EXPLAIN 和结果校验。
