下划线_匹配单个任意字符，%匹配零个或多个任意字符；需用escape显式指定转义符（如escape ''）才能查询字面值%或_，否则会被误作通配符导致误匹配。
SQL里_和%到底匹配什么？
不是所有“任意字符”都用%——_（下划线）匹配单个任意字符，%匹配零个或多个任意字符。比如'a_c'能匹配'abc'或'axc'，但不匹配'ac'；而'a%c'能匹配'ac'、'abc'、'a123c'甚至'ac'（中间零字符也算）。
LIKE语句中转义特殊字符的坑
当你要查真实包含%或_的字符串（比如产品编码'SKU_2024%'），直接写WHERE code LIKE '%_%'会全表误匹配。必须显式指定转义符：
WHERE code LIKE '%_%' ESCAPE ''
注意三点：
-
ESCAPE后面只能跟单个字符，且该字符在模式串中必须用%、_形式出现 - 不同数据库默认转义符不同：PostgreSQL默认无转义，MySQL默认
，SQL Server默认无，别依赖默认值 - 如果模式本身含转义符（比如想查
'path ile'），得写成'path\file'并声明ESCAPE ''
正则替代方案：什么时候该放弃LIKE？
当需求超出%/_能力时——比如“匹配3位数字后跟字母A或B”，LIKE写不出来，就得换正则：
- MySQL用
REGEXP：WHERE col REGEXP '^[0-9]{3}[AB]$' - PostgreSQL用
~操作符：WHERE col ~ '^[0-9]{3}[AB]$' - SQL Server 2017+需用
STRING_SPLIT配合CLR或外部函数，原生不支持正则
性能上，LIKE前导通配符（如'%abc'）基本无法走索引，正则更慢，真要高频查询建议加计算列+索引
大小写敏感性导致匹配失败
LIKE是否区分大小写，完全取决于字段的排序规则（collation）。例如：
- MySQL中
utf8mb4_0900_as_cs是大小写敏感，utf8mb4_0900_ai_ci是不敏感且忽略重音 - SQL Server若列用
Latin1_General_CI_AS，则'ABC' LIKE 'abc'返回TRUE - 最稳妥的方式是显式转换：
UPPER(col) LIKE UPPER('a%b')，但会丢失索引优势
真正容易被忽略的是：同一个数据库里，不同字段可能有不同collation，连JOIN条件都可能因大小写行为不一致出错
