下划线_匹配单个任意字符，%匹配零个或多个任意字符；需用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条件都可能因大小写行为不一致出错