mysql中\表示一个反斜杠：sql层解析一次得，若经python等语言拼接还需语言层转义，故需写\\；推荐用原始字符串或参数化查询避免问题。

MySQL 里 \ 到底是几个反斜杠？

MySQL 默认把 当作转义字符，所以写进 SQL 的 \ 实际会被解析成一个 ；但如果你用的是 Python 或 Java 这类语言拼 SQL，字符串本身还要过一遍语言层的转义——结果就是你得写 \\ 才能在数据库里存下真实的 。

常见错误现象：INSERT INTO t VALUES ('C: empile.txt') 直接报错或存成 C: empile.txt，因为 和  被当成了制表符和换页符。

• 在 MySQL 客户端里手动执行时，\ → 存入一个
• 用 Python 的 cursor.execute() 拼接字符串时，Python 字符串先解析一次："C:\temp\file.txt" → 传给 MySQL 的是 C: empile.txt → MySQL 再解析一次 → 最终存成 C: empile.txt
• 正确做法：要么用原始字符串 r"C: empile.txt"，要么统一用参数化查询（推荐）

PostgreSQL 怎么处理 和 E''？

PostgreSQL 默认不启用反斜杠转义（standard_conforming_strings = on），所以普通字符串里的 就是字面量，不会被特殊处理；但如果你开了 escape 模式或者用了 E'' 语法，它就变成 PostgreSQL 自己的转义规则了。

使用场景：从 MySQL 迁移数据、或需要插入 Unicode 字符（如 E'u4f60'）时容易踩坑。

• 默认情况下，SELECT 'C: emp'; 返回的就是 C: emp，没毛病
• 但 SELECT E'C: emp'; 会把 解释成制表符，输出带空白的字符串
• 想强制按字面量处理又必须用 E''？那就双写反斜杠：E'C:\temp'
• 检查当前行为：SHOW standard_conforming_strings; —— 返回 on 是安全的，默认模式

参数化查询为什么能绕过所有转义问题？

因为参数化查询（prepared statement）把值和 SQL 结构完全分开，数据库驱动负责把值以二进制或协议原生方式传过去，根本不经过 SQL 字符串解析阶段——也就彻底跳过了 转义这一步。

性能 / 兼容性影响：几乎所有现代驱动都支持，且比字符串拼接快（预编译可复用），还能防注入。唯一代价是你不能拿参数去动态拼表名或列名。

• Python + psycopg2：cur.execute("INSERT INTO t (path) VALUES (%s)", [r"C: empile.txt"])
• Node.js + pg：client.query("INSERT INTO t (path) VALUES ($1)", ["C:\temp\file.txt"]) —— 这里 JS 字符串要转义，但传到 PG 后不会二次解析
• Java + JDBC：ps.setString(1, "C:\temp\file.txt"); 同理，JDBC 驱动自动处理传输格式

LIKE 查询里怎么匹配真实的 字符？

LIKE 语句里 既是 SQL 字符串的转义符，又是通配符的转义符（比如 %），两层含义叠在一起，最容易漏掉 ESCAPE 子句。

常见错误现象：WHERE path LIKE '%%' 想查含 % 的路径，结果语法错误；或者写成 '%\%'，却匹配到了所有行——因为没声明哪个字符是 LIKE 的转义符。

• 必须显式指定：WHERE path LIKE '%%' ESCAPE ''，这样第一个 告诉 LIKE “下一个字符别当通配符”，第二个 是你要匹配的真实字符
• 如果字段里存的是 C: emp，而你想查所有 Windows 路径，得写：WHERE path LIKE '%C:\%' ESCAPE ''（注意：SQL 层只认一个 ，所以写两个）
• 更稳妥的做法：改用正则（~ in PG，REGEXP in MySQL），避开 LIKE 的双重转义逻辑

最麻烦的其实是嵌套场景：比如 JSON 字段里存了带反斜杠的路径，再用 JSON_EXTRACT 或 ->> 取出来，中间可能经历 JSON 解析、SQL 字符串解析、LIKE 解析三道关卡——这时候靠数反斜杠已经不可靠，得逐层确认每个环节的转义开关状态。