必须显式声明ESCAPE子句，否则%和_在LIKE中始终被当作通配符；正确写法是LIKE '%10!%%' ESCAPE '!'，用生僻字符如!作转义符可避免冲突。
LIKE子句里%和_被当成通配符怎么办
直接用 ESCAPE 指定转义字符，否则 % 和 _ 在 LIKE 中永远优先匹配，哪怕你查的就是字面量 "10%"。标准写法是加 ESCAPE 子句并配合反斜杠或其它单字符前缀。
常见错误是只写 % 却没声明 ESCAPE，结果数据库照常把 % 当通配符处理，查不到任何含字面 % 的记录。
- 必须成对出现：
LIKE '10%' ESCAPE ''—— 不写ESCAPE，前面的%无效 - 转义字符只能是单个字符，不能是字符串（如
ESCAPE '\'是错的，ESCAPE ''才对） - 如果字段值本身含转义字符（比如存了
"price: 50%"），而你又用作转义符，就会误匹配或漏匹配 - 部分数据库（如 PostgreSQL）默认不支持反斜杠转义，需先设
standard_conforming_strings = off或改用其他字符如!
用什么字符当ESCAPE最安全
选转义字符得避开数据里高频出现的符号。用 看似自然，但在 Windows 路径、JSON、正则中太常见；用 / 可能在 URL 字段里冲突；最稳妥的是挑一个几乎不会出现在业务数据里的字符，比如 !、~ 或 ^。
示例：WHERE name LIKE '%10!%%' ESCAPE '!' 表示查包含字面 "10%" 的记录，这里第一个 ! 转义紧随其后的 %，后面那个 % 仍是通配符。
-
ESCAPE '!'后，!本身在模式中必须写成!!才表示字面感叹号 - MySQL 默认允许
，但开启NO_BACKSLASH_ESCAPESSQL 模式后会失效，此时必须显式指定其它转义符 - SQL Server 对
ESCAPE支持较晚（2005+），旧版本只能靠CHARINDEX或REPLACE曲线救国
ESCAPE在不同数据库里的行为差异
不是所有数据库对 ESCAPE 的解析逻辑一致。PostgreSQL 严格要求转义字符不能是通配符本身（即不能 ESCAPE '%'），而 SQLite 允许，但效果不可靠；Oracle 则要求转义字符必须是 ASCII 可打印字符，且不能是空格。
- MySQL：支持
ESCAPE，但若模式中转义字符后跟非特殊字符（如'ac'），会原样匹配字符，不报错也不警告 - PostgreSQL：若写
LIKE 'foo%' ESCAPE ''，必须确保客户端连接未启用standard_conforming_strings，否则反斜杠会被当作字符串转义而非LIKE转义 - SQLite：支持
ESCAPE，但不校验转义字符是否合法，ESCAPE ''（空字符串）会导致整个LIKE行为异常
想模糊查带中括号的字符串时怎么写
方括号 [ 和 ] 在某些数据库（如 SQL Server）里是字符集语法的一部分，不属于标准 SQL 的 LIKE 特殊字符，但若你确实要匹配字面 [abc]，不能只靠 ESCAPE —— 得结合 [] 字符范围语法或改用正则。
例如 SQL Server 中查字段值等于 "[test]"，正确写法是：WHERE col LIKE '[test]' ESCAPE ''。这里 [ 和 ] 分别转义左右括号，因为它们在 SQL Server 的 LIKE 中有特殊含义。
- 标准 SQL 不定义
[为特殊字符，所以 PostgreSQL/MySQL 下直接写'[test]'就能精确匹配，无需ESCAPE - 如果跨数据库兼容性重要，避免依赖
[语义，改用POSITION('[test]' IN col) > 0或INSTR(col, '[test]') > 0更稳妥 - Oracle 用户注意：
ESCAPE后不能跟 Unicode 多字节字符，哪怕显示为单个符号也不行
ESCAPE，再挑一个数据里绝不会出现的字符当转义符，最后检查模式串里每个待转义字符前是否真有且仅有一个转义符——少一个就变通配，多一个就可能匹配失败。 
