LIKE查询中必须转义的字符是%、_、；不同数据库转义语法各异，推荐预处理输入并统一使用安全转义符（如!），避免直接拼接用户数据引发错误。
LIKE查询中哪些字符必须转义
SQL标准里只有 % 和 _ 是 LIKE 的通配符，但实际使用中，如果你要查的字段值本身就含这两个字符（比如用户输入了 "100%" 或 "user_name"），不转义就会被误匹配。另外，部分数据库（如 PostgreSQL）还把 当作默认转义符，它自己也得处理——所以真正要小心的是这三个： %、_、。
不同数据库的转义语法差异
不是所有数据库都用 ESCAPE 子句，也不是都默认认 ：
- MySQL / PostgreSQL / SQL Server：支持
ESCAPE，可自定义转义符，例如WHERE name LIKE '100%' ESCAPE '' - SQLite：只支持
ESCAPE，且转义符必须是单字符，不能省略 - Oracle：默认用
作转义符，但必须显式声明ESCAPE ''，否则%不生效 - 注意：PostgreSQL 在字符串字面量里写
'%'会被解释为普通%，因为反斜杠先被字符串解析器吃掉了——得写成'\%'或改用ESCAPE '$'避开
安全拼接用户输入的LIKE参数
直接拼字符串极易出错，尤其当用户输入含 或多个 % 时。推荐做法是预处理原始值，而不是靠 ESCAPE 临时兜底：
- 先统一选一个安全转义符（比如
!），避免和用户数据冲突 - 对原始输入做替换：
input.replace(/([%!_])/g, '!$1')（JS）或REPLACE(REPLACE(REPLACE(input, '!', '!!'), '%', '!%'), '_', '!_')（SQL Server） - 再拼进查询：
WHERE col LIKE '!100!%' ESCAPE '!' - 别用
作转义符处理用户输入——MySQL 8.0+ 默认开启NO_BACKSLASH_ESCAPES，%可能直接报错
用正则替代LIKE是否更简单
某些场景下确实更可控，但要注意代价：
- PostgreSQL 支持
~操作符（WHERE col ~ '^100%$'），但%在正则里没特殊含义，得手动转义成%；而_要写成.，语义已变 - MySQL 8.0+ 有
REGEXP_LIKE()，但性能通常比LIKE差，尤其没索引支持时 - 如果只是查固定前缀（如
name LIKE 'abc%'），用=或BETWEEN+ 索引更高效，根本不用碰转义
转义本身不难，难在统一处理边界情况：用户输 "a_b%c" 时，你得知道它在当前数据库里到底被解析成几个层级的转义——这往往比写查询本身花的时间还多。
