下划线_在sql insert中无需转义，仅在like模糊查询中作为单字符通配符生效；正确处理方式是使用escape子句（如like 'test#_user' escape '#'）或预处理语句参数化，避免字符串拼接。
SQL插入时下划线_被当作通配符导致数据错乱
下划线_在SQL的LIKE语句里是单字符通配符，但如果你只是普通INSERT，它本身不会引发语法错误——真正出问题的地方，是当你把含_的字符串拼进动态SQL、或用在WHERE条件里做模糊匹配时，结果查不到或删多了。
所以关键不是“插入时要转义_”，而是：你有没有在后续查询中无意把它当通配符用了？
- 如果只是
INSERT INTO user (name) VALUES ('test_user');——完全不用处理，_就是字面量 - 如果之后执行
SELECT * FROM user WHERE name LIKE 'test%';——依然安全，%才管用 - 但如果写成
SELECT * FROM user WHERE name LIKE 'test_user';——这时_会匹配任意一个字符，test_user可能被当成testAuser、test9user一起查出来
用ESCAPE指定转义符解决LIKE中的_
想让_在LIKE里变回普通字符，得靠ESCAPE子句，而不是给INSERT加反斜杠。
- 正确写法：
WHERE name LIKE 'test_user' ESCAPE ''（MySQL/PostgreSQL） - Oracle默认用
，但需显式声明：WHERE name LIKE 'test_user' ESCAPE '' - SQL Server支持
ESCAPE，也允许用[%_]这种字符类写法，但可读性差，不推荐 - 别写
WHERE name = 'test_user'来绕开？可以，但前提是你要的是精确匹配——如果业务真需要模糊查“test开头、user结尾”，那就必须用LIKE+ESCAPE
预处理语句（Prepared Statement）才是防注入+保字面量的正解
手动拼SQL、自己加转义符，既容易漏，又难维护。真正稳的方式是绕过字符串拼接，让数据库驱动处理字面量。
- Python用
cursor.execute("INSERT INTO t (col) VALUES (%s)", ["test_user"])——_原样入库，无任何转义动作 - Java用
PreparedStatement：ps.setString(1, "test_user");——底层自动绑定，不经过SQL解析阶段 - Node.js的
pg或mysql2同理，参数占位符$1或?都走二进制协议传值，_根本不会被SQL引擎当通配符看 - 注意：如果用
query("INSERT ... '" + val + "'")这种拼接，哪怕加了_也没用——因为转义发生在应用层，而数据库收到的可能是双重解析后的结果
PostgreSQL里LIKE默认不认
PostgreSQL严格遵循标准，不是默认转义字符，直接写'test_user' ESCAPE ''会报错ERROR: invalid escape string，因为服务器没开standard_conforming_strings或没设escape上下文。
- 方案一（推荐）：
WHERE name LIKE 'test#_user' ESCAPE '#'，用#代替，避免和反斜杠兼容性扯皮 - 方案二：在连接串里加
options=-c%20standard_conforming_strings=on（URL编码后），但依赖客户端配置，不好控 - 别信“加两个
\就行”——那是在字符串字面量里逃逸反斜杠本身，和SQL转义逻辑不在一层
真正麻烦的从来不是下划线本身，而是你以为它在INSERT里要处理，其实该盯紧的是后续怎么查；你以为加个反斜杠就完事，结果不同数据库对ESCAPE的默认行为根本不一致。
