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