应使用ESCAPE指定转义符，如WHERE username LIKE 'admin!_%' ESCAPE '!'，将字面下划线或百分号前加转义符，避免被误作通配符匹配。
LIKE 查询中下划线 _ 和百分号 % 被当成通配符怎么办
MySQL 的 LIKE 默认把 _（匹配单个字符）和 %（匹配任意长度字符串）当作通配符，不是字面意思。如果你查字段值里真实包含这两个字符的记录（比如用户名是 admin_2024 或邮箱含 test%user@example.com），直接写 WHERE name LIKE '%admin_%' 会误匹配 admin123、adminX 等所有带“admin+任意单字符”的结果。
解决办法是用 ESCAPE 指定一个转义字符，再在要当字面量的 _ 或 % 前加它。常见选 、! 或 | ——只要不和你要查的文本冲突就行。
-
SELECT * FROM users WHERE username LIKE '%admin_%' ESCAPE '';——用反斜杠转义_ -
SELECT * FROM logs WHERE message LIKE '%error!%%' ESCAPE '!';——用叹号转义后面的%，第一个%仍是通配符 - 注意：转义字符本身如果出现在数据中，也要被转义，比如查字符串
path ile，得写LIKE '%path\file%' ESCAPE ''
为什么用 ESCAPE 比用 REGEXP 更合适
有人想到用 REGEXP 绕过转义问题，比如 WHERE username REGEXP 'admin_[0-9]+'。但这是高成本方案：正则引擎比 LIKE 慢得多，且无法利用普通 B+Tree 索引（除非用生成列+函数索引，太重）。而 LIKE 加 ESCAPE 仍走索引前缀匹配，只要模式开头不是通配符（如 'admin_%' 可用索引，'%_%' 就不行）。
- 只查固定前缀 + 字面特殊字符 → 优先用
LIKE ... ESCAPE - 需要复杂模式（如“数字后跟下划线再跟字母”）→ 才考虑
REGEXP，并确认执行计划是否走索引 - MySQL 8.0+ 支持
LIKE中用方括号定义字符集（如[a-z]），但不支持转义_/%，所以ESCAPE仍是刚需
ESCAPE 字符选错会导致语法错误或逻辑错误
错误不是报“转义失败”，而是直接报错或查不到数据。典型陷阱：
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
- 选的转义字符本身在 pattern 中没被用来转义任何东西 → MySQL 不报错，但
ESCAPE形同虚设（比如LIKE 'abc' ESCAPE '|'，没用到|，就等于没写ESCAPE） - 转义字符是 SQL 特殊字符（如
'、"、）→ 必须在字符串里正确表示：用'\'表示单个反斜杠，否则语句解析失败 - 客户端或 ORM 自动转义（如 PHP 的
mysqli_real_escape_string）可能把你的再转成\，导致实际传给 MySQL 的是双反斜杠 → 查不到数据。此时要么换转义符（如改用!），要么关掉自动转义
在参数化查询里怎么安全拼 ESCAPE 子句
预处理语句不能把 ESCAPE 后的字符当参数绑定（MySQL 不允许占位符出现在 ESCAPE 关键字后）。必须拼进 SQL 字符串，但要严格校验输入：
- 转义符只能从白名单选：
'\'、'!'、'|'、'^'——避免用户控制任意字符 - pattern 中所有待转义的
_和%必须提前用选定的转义符“打标”，不能依赖运行时替换（易漏或重复转义） - 示例（Python + mysql-connector）：
escape_char = '\'<br>search_term = 'admin_%'<br># 手动转义：把 '_' → '_', '%' → '%'<br>escaped_term = search_term.replace('_', f'{escape_char}_').replace('%', f'{escape_char}%')<br>query = f"SELECT * FROM users WHERE username LIKE %s ESCAPE '{escape_char}'"<br>cursor.execute(query, (f'%{escaped_term}%',))
真正容易被忽略的是：不同客户端对反斜杠的处理层级不一致，有时要双重转义；测试时务必用真实数据跑一遍执行计划（EXPLAIN），确认 key_len 和 type 是否符合预期。
