%匹配零个或多个任意字符，_仅匹配一个任意字符；二者需用ESCAPE转义字面值，前置%导致索引失效，NULL不匹配任何LIKE表达式。
LIKE 不是函数，是 SQL 标准操作符，直接写在 WHERE 子句里就能用；但写错通配符位置、忽略转义、不考虑性能，很容易查不到数据或拖垮查询。
LIKE 的基本写法和通配符含义
核心就两条规则：% 匹配零个或多个任意字符，_ 匹配且仅匹配一个任意字符。它们必须放在单引号内，作为字符串模式的一部分。
-
name LIKE '张%'→ 查“张三”“张小花”“张”，但不查“李张” -
name LIKE '%张%'→ 查所有含“张”的，比如“王张明”“张建国”“阿张” -
name LIKE '张_'→ 只查两个字、且首字为“张”的，如“张伟”“张敏”，不查“张三丰”或“张” -
name LIKE '___'→ 查所有恰好 3 个字符的值（注意：中文算 1 个字符，不是字节）
查的内容本身含 % 或 _ 怎么办
如果你要查用户名就是 admin%，或者订单号含下划线如 ORD_2024，直接写 LIKE '%admin%%' 或 LIKE '%ORD_%' 会误匹配——因为 % 和 _ 被当成通配符解析了。
- 最稳妥的方式是用
ESCAPE指定转义符，例如：LIKE '%admin\%%' ESCAPE '\'，这时中间的\%才表示字面意义的百分号 - SQL Server 支持方括号转义：
LIKE '%admin[%]%'或LIKE '%ORD[_]2024%' - MySQL 默认不支持方括号转义，必须显式声明
ESCAPE，否则[%]会被当作字符集语法处理 - 别用反斜杠直接拼接（如
'%admin\%'），不同数据库对未声明ESCAPE的反斜杠处理不一致，MySQL 8.0+ 默认禁用这种隐式转义
为什么查得慢？索引失效的常见原因
当 LIKE 模式以 % 开头（如 LIKE '%keyword'），绝大多数数据库无法使用 B-tree 索引，只能全表扫描——哪怕字段加了索引也没用。
- 能走索引的写法只有：
LIKE 'prefix%'（前缀匹配）、LIKE 'exact_string'（无通配符，等价于=） -
LIKE '%suffix'或LIKE '%in%middle%'都不走索引，除非你建了全文索引（FULLTEXT）或使用pg_trgm（PostgreSQL）这类扩展 - MySQL 中如果字段是
utf8mb4字符集，又用了LIKE+%开头，还可能触发字符集隐式转换，进一步恶化性能 - 测试是否走索引？在 MySQL 中用
EXPLAIN看type是否为range或ref；在 PostgreSQL 中看执行计划有没有Index Scan
大小写和 NULL 值容易被忽略的细节
默认行为因数据库而异，不能假设“都一样”。
- MySQL 默认不区分大小写（取决于字段 collation，如
utf8mb4_0900_as_cs才区分），想强制区分就加BINARY：BINARY name LIKE 'Admin%' - PostgreSQL 默认区分大小写，要忽略大小写得用
ILIKE，或者写LOWER(name) LIKE LOWER('admin%') -
name LIKE '%a%'永远不会匹配name IS NULL的行，NULL 不参与任何LIKE判断，必须单独写OR name IS NULL - 空字符串
''和 NULL 不同：name = ''是有效比较，name LIKE ''也能匹配空字符串，但不会匹配 NULL
真正麻烦的不是语法记不住，而是上线后才发现某条 LIKE '%关键词%' 在百万级表上跑了 8 秒——这时候再改逻辑或加索引，已经卡在业务路径上了。
