下划线_在sql like中是单字符通配符，匹配任意一个字符；需用escape子句转义才能匹配字面量下划线，如where name like 'user\_name' escape '\'。
LIKE 查询中下划线被当作通配符导致误匹配
SQL 的 LIKE 中，下划线 _ 是单字符通配符（匹配任意一个字符），不是字面量。所以直接写 WHERE name LIKE 'user_name' 会匹配 userAname、user1name 等，而非真实含下划线的字符串。
用 ESCAPE 指定转义字符来匹配字面量下划线
标准且兼容性最好的方式是显式声明转义字符，然后对 _ 进行转义。不同数据库语法一致，但需注意转义字符本身不能出现在待查字符串中（或需双重转义）。
- 写法：在
LIKE后加ESCAPE 'x'，然后把_写成x_ - 常用转义字符选
\或!，例如：WHERE name LIKE 'user\_name' ESCAPE '\' - PostgreSQL 默认不启用反斜杠转义，需额外设置
standard_conforming_strings = on，否则推荐用!避坑：WHERE name LIKE 'user!_name' ESCAPE '!' - MySQL 和 SQL Server 对
\_支持较好，但仍建议统一用ESCAPE子句，避免依赖默认行为
某些数据库支持方括号或反引号包裹（非标准，慎用）
SQL Server 允许用方括号把下划线包起来：WHERE name LIKE 'user[_]name'；MySQL 5.7+ 在 ANSI 模式下可用反引号：WHERE name LIKE 'user`_`name'。但这些写法：
- 不具备跨库可移植性
- 方括号在 PostgreSQL 或 SQLite 中会报错
- 反引号在 SQL Server 中是非法的
- 一旦换数据库或迁移 schema，这类查询大概率失效
需要模糊匹配又含下划线时，注意转义位置和范围
如果想查“以 log_ 开头、后跟任意两个字符的字符串”，错误写法是 LIKE 'log_%'（_ 仍被当通配符）。正确做法是：
- 只转义真正要当字面量的下划线：
LIKE 'log\___' ESCAPE '\'（一个转义_+ 两个未转义_） - 若整个字段值固定含多个下划线，比如
order_id，应全部转义：LIKE 'order\_id%' - 动态拼接 SQL 时，务必对用户输入中的
_和%做预处理，否则可能引发逻辑漏洞或全表扫描
最容易被忽略的是：ESCAPE 字符本身如果出现在原始数据里（比如查 path\file），就得把它也转义——这意味着你得先定义好转义规则，并在应用层统一处理，而不是只想着解决下划线。
