%匹配任意长度（含零个）字符，_仅匹配单个任意字符；误用_会导致定长匹配错误，如'abc_'只匹配4位字符串；需注意转义、索引失效及collation影响。
LIKE 查询中 % 和 _ 的行为差异必须分清
百分号 % 匹配任意长度（含零个）字符，下划线 _ 只匹配单个任意字符。误用 _ 当作通配符是初学者高频错误——比如想查所有含 "abc" 的字段却写成 WHERE col LIKE 'abc_'，结果只返回刚好 4 位且前三位是 abc 的数据。
实际使用建议：
- 模糊匹配开头：用
LIKE 'prefix%'（如查以 "http" 开头的 URL） - 模糊匹配结尾：用
LIKE '%suffix'（如查 ".jpg" 结尾的文件名） - 中间包含某串：用
LIKE '%target%'（最常用，但性能开销大） - 精确长度 + 部分已知：才用
_，例如LIKE 'A_C'匹配 "ABC"、"A2C"，但不匹配 "AC" 或 "ABCD"
中文、特殊字符和转义字符容易漏掉 ESCAPE
当要查的字符串本身含 % 或 _（比如查折扣率字段值为 "50%"），直接写 WHERE rate LIKE '50%' 会被当成“以 50 开头的任意字符串”，必须声明转义符：
WHERE rate LIKE '50!%' ESCAPE '!'
注意：ESCAPE 后只能跟单个字符，且该字符在模式串中出现时需加在待转义符号前。常见坑：
- 忘了写
ESCAPE子句，导致查询逻辑错乱 - 转义符选了 SQL 关键字（如
ESCAPE 'a'没问题，但ESCAPE 'AS'会报语法错误） - 在参数化查询中，转义符和模式串都需由应用层拼接，不能只转义用户输入部分
LIKE 性能差？索引是否生效要看左侧是否有通配符
LIKE 'abc%' 可走 B-Tree 索引（前缀匹配），LIKE '%abc' 或 LIKE '%abc%' 基本无法利用常规索引，全表扫描概率高。MySQL 5.7+、PostgreSQL 支持函数索引或表达式索引缓解，但不是万能解。
优化方向：
- 避免
LIKE '%...%'在大表主查询中使用，考虑拆出关键词建倒排表或引入全文检索（如 MySQLFULLTEXT、PostgreSQLtsvector） - 若业务允许，把模糊逻辑移到应用层：先用等值条件缩小范围（如按分类 ID 过滤），再内存里做字符串匹配
- SQL Server 用户可考虑
CONTAINS()替代，但需提前开启全文索引
大小写敏感性取决于字段 collation，不是 LIKE 本身
LIKE 本身不决定大小写行为，真正起作用的是字段的排序规则（collation）。例如：
-
utf8mb4_0900_as_cs：区分大小写（case-sensitive） -
utf8mb4_0900_ai_ci：不区分大小写（case-insensitive）
验证当前字段规则：
SHOW FULL COLUMNS FROM table_name WHERE Field = 'col_name';
临时强制大小写敏感（MySQL）：
WHERE col COLLATE utf8mb4_0900_as_cs LIKE 'AbC%'
注意：COLLATE 会阻止索引使用，仅限必要场景临时加。
LIKE 看似简单，但 collation、转义、索引这三块最容易在线上查不出数据或拖慢整条 SQL。别只盯着通配符写法，先看执行计划（EXPLAIN），再确认字段排序规则，最后补转义——顺序错了，调半天也白搭。
