%匹配任意长度（含零）字符，_仅匹配一个字符；二者是通配符而非字面符号，需用ESCAPE显式转义才能查字面值，否则会导致语义错乱或漏匹配。
LIKE里%和_为什么不能直接当普通字符用
因为%匹配任意长度字符串（含零个），_匹配且仅匹配一个任意字符——它们在LIKE语义里不是字面符号，而是通配符。写WHERE name LIKE 'user_%'，实际会匹配userA、user （空格）、user1，而不是只找user_开头的记录。
必须用ESCAPE显式声明转义符，不能依赖反斜杠默认生效
标准SQL要求用ESCAPE子句指定单字符作转义符，数据库不会自动把当转义符（尤其MySQL在NO_BACKSLASH_ESCAPES模式下会直接忽略）。错误写法：WHERE tag LIKE '%50%'；正确写法：WHERE tag LIKE '%50!%' ESCAPE '!'。
-
ESCAPE后面的字符必须是单个ASCII可打印字符，推荐!、$或|——这些在业务数据中极少出现 - 转义符本身若出现在原始数据里（比如用户昵称含
!），那这条记录就永远无法被该LIKE条件命中 - 转义只作用于
ESCAPE后紧跟的那个字符：在'A!_B%' ESCAPE '!'中，只有!后面的_被转义，末尾的%仍是通配符
不同数据库对反斜杠的处理差异极大
MySQL默认把当字符串转义符，导致'%100%'传给LIKE引擎前可能已被解析成'%100%'；PostgreSQL默认不解释，但若用E''字面量就必须写E'%100\%'；SQL Server更倾向用方括号：WHERE name LIKE '%[_]%'。
- 跨库项目一律避开
，统一用ESCAPE '!'写法 - PostgreSQL里如果字段值含
!，又用!作转义符，LIKE会完全跳过该行——这不是bug，是规范行为 - 别信“加两个反斜杠就安全”的经验，MySQL 8.0+ 和旧版对
SQL_MODE敏感，结果不可预测
参数化查询不自动处理LIKE转义
PreparedStatement防SQL注入，但不改LIKE语义。传入"50%"，WHERE desc LIKE ?仍按通配符匹配。必须在应用层先转义再传参。
- 用户输入
"disk % drive"→ 应用层替换为"disk !% drive"→ SQL写成WHERE desc LIKE ? ESCAPE '!' - ORM如MyBatis，
#{}不自动转义，得用<bind></bind>或Java层预处理 - 如果原始输入里已含转义符（比如用户搜
"cost!%"），要先对!做二次转义：变成"cost!!%"，否则ESCAPE '!'会把它误判为转义动作
LIKE就既不安全也不准确。 
