MySQL中LIKE的%匹配任意长度字符（含零），_仅匹配单个字符；需用ESCAPE转义字面%或_；前缀固定如'abc%'可走索引，'%abc'则全表扫描；大小写敏感性由字段collation决定。
LIKE 里的 % 和 _ 到底怎么匹配
MySQL 的 LIKE 不是正则，% 匹配任意长度（含零）的字符，_ 只匹配单个字符——仅此而已，不支持 +、? 或范围写法。
常见错误是把 % 当成“通配多个字”，结果写成 name LIKE '%张%三%' 还以为能精确匹配“张三”，其实它也会命中“张小三”“张三丰”“王张三”。真要找完整词，得结合边界或用全文索引。
-
%可以放在开头、中间、结尾，但开头带%（如LIKE '%abc'）基本无法走索引，查得慢 -
_必须对应一个真实字符，LIKE 'a_c'能匹配abc、a2c，但不匹配ac（缺一位）或abcd（多一位） - 如果字段值本身含
%或_（比如用户昵称叫“100%帅”），必须用ESCAPE指定转义符，否则会被当通配符处理
如何安全地搜索含百分号或下划线的原文
用户输入里带 % 或 _ 是高频翻车点。直接拼进 SQL，WHERE name LIKE '100%' 实际查的是“以 100 开头的任意字符串”，不是字面的“100%”。
正确做法是显式声明转义符，并在用户输入中对特殊字符预处理：
- 选一个不会出现在业务数据里的字符做转义符，比如
：LIKE '100%' ESCAPE '' - 代码层要把用户输入中的
%、_、全部替换成%、_、\，再拼进 SQL - 别图省事用
REPLACE(name, '%', '%')做运行时替换——这改的是字段值，不是模式串，没用
LIKE 性能差？先看有没有走索引
LIKE 慢，往往不是语法问题，而是索引没生效。只有当前缀固定时，B+ 树索引才可能用上：
-
LIKE 'abc%'→ 可走索引（最左匹配） -
LIKE '%abc'或LIKE '%abc%'→ 索引失效，全表扫描 -
LIKE 'ab_c'→ 可走索引（c是确定字符，前面ab固定） - 字段是
TEXT或没建索引，再怎么写模式也白搭
如果业务真要频繁做前后模糊搜，FULLTEXT 索引或外部搜索引擎（如 Elasticsearch）比硬扛 LIKE 更靠谱。
区分大小写和字符集影响匹配结果
MySQL 的 LIKE 是否区分大小写，取决于字段的排序规则（collation）。默认 utf8mb4_general_ci 是不区分的，utf8mb4_bin 就区分。
-
SELECT 'AbC' LIKE 'abc';在_ci规则下返回1，在_bin下返回0 - 中文场景下，某些老 collation（如
utf8mb4_unicode_ci）对拼音、笔画不敏感，'张'和'章'可能被当成相同 - 临时强制大小写敏感：加
BINARY，如WHERE BINARY name LIKE 'AbC%'
字符集和 collation 是建表时定的，后期改要小心，尤其线上大表。查匹配异常时，先 SHOW CREATE TABLE 看清楚字段定义。
