不同数据库中LIKE查询的反斜杠并非默认转义符：MySQL 5.7+默认支持，PostgreSQL、SQL Server、SQLite不认，需显式用ESCAPE指定转义字符或SQL Server用方括号语法。
LIKE 查询中反斜杠不是默认转义符
SQL 标准里 LIKE 的通配符是 % 和 _，但它们本身也是普通字符——想查真实存在的百分号，就得告诉数据库“别当通配符用”。关键是：**不同数据库默认不认 是转义符**。MySQL 5.7+ 默认用 ，但 PostgreSQL、SQL Server、SQLite 完全不认，直接写 LIKE '%%%' 会报错或逻辑错误。
正确做法是显式声明转义字符：
- MySQL：用
ESCAPE '\'（注意字符串里要写两个反斜杠） - PostgreSQL：必须用
ESCAPE '!'这类单字符，且该字符不能出现在要匹配的文本里 - SQL Server：推荐用方括号语法
LIKE '%[%]%'，比ESCAPE更直观可靠
示例（查含真实 % 的字段）：
SELECT * FROM logs WHERE message LIKE '%%%' ESCAPE ''; -- MySQL
SELECT * FROM logs WHERE message LIKE '%!%%' ESCAPE '!'; -- PostgreSQL
方括号语法在 SQL Server 中更安全
SQL Server 的 [] 是字符字面量包装器，比 ESCAPE 少一堆歧义。比如查含 [、]、%、_ 的数据，不用记哪个字符要转义、哪个是转义符本身。
常见写法：
-
LIKE '%[[]%'匹配含左方括号[的字符串（第一个[开始字符集，第二个[是字面量） -
LIKE '%[]%'不行——右括号]必须紧跟在开头，即LIKE '%[]]%' -
LIKE '%[_]%'匹配含下划线字符，不是通配含义
注意：方括号只对单个字符生效，[a-z] 是范围，[[] 才是字面 [。
正则表达式比 LIKE 更适合复杂特殊字符场景
当要同时匹配多个特殊字符（如
、 、控制字符、Unicode 符号），LIKE 力不从心。这时候得看数据库是否支持正则：
- PostgreSQL：用
~操作符，SELECT * FROM users WHERE name ~ E'\t.*\n'; - MySQL 8.0+：用
REGEXP，注意双反斜杠：WHERE content REGEXP '\\x00'; - SQL Server：没有原生正则，得用
CHARINDEX或 CLR 函数，或者升级到 2022+ 用STRING_SPLIT配合LIKE
正则里真正需要转义的是正则元字符（.、*、+、? 等），和 LIKE 的转义体系完全独立——别混用 ESCAPE 和正则反斜杠。
CHAR() 和 ASCII() 是定位不可见字符的底层手段
有些“特殊字符”根本打不出来，比如 ASCII 0（NULL）、ASCII 7（响铃）、UTF-8 BOM 头。这时 LIKE 和正则都可能失效，得靠字节级判断。
通用技巧：
- 用
ASCII(SUBSTRING(col, n, 1))查第 n 位字符的 ASCII 值（SQL Server / MySQL） - PostgreSQL 用
get_byte(col::bytea, n) - MySQL 8.0+ 可用
ORD()替代ASCII() - 查 BOM：
HEX(LEFT(content, 3)) = 'EFBBBF'（UTF-8）
这类操作性能差，别放 WHERE 条件里全表扫；先用应用层或导出后用脚本筛一遍更实际。
真正难的不是写对语句，而是确认你看到的“空格”到底是 CHAR(32)、CHAR(160)（NBSP）、还是 U+200B（零宽空格）——肉眼无法区分，必须靠编码工具验证。
