中文like匹配结果取决于字段collation，如utf8mb4_general_ci会将“张”“張”“弡”视为相同，而utf8mb4_0900_as_cs则区分；前缀匹配可走索引，但通配符在中间或末尾时索引失效；需转义%和_，且like不匹配null。
中文字段的排序规则决定匹配行为
LIKE 对中文的处理不是“能不能用”的问题，而是“怎么算相等”的问题——它完全取决于字段的 COLLATION。同一个 WHERE name LIKE '张%' 在 utf8mb4_general_ci 和 utf8mb4_0900_as_cs 下可能返回不同结果。
常见陷阱：
- MySQL 中
utf8mb4_general_ci会把“张”“張”（繁体）、“弡”（异体）视为相同字符，导致意外命中 - PostgreSQL 默认使用
en_US.UTF-8排序规则，区分大小写且不折叠汉字变体，“张”≠“張” - 字段定义为
VARCHAR(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci才较稳妥支持多音字、简繁混搜
查当前字段排序规则：SHOW FULL COLUMNS FROM users LIKE 'name';
LIKE '%关键词%' 在中文场景下的性能现实
中文词不像英文有天然空格分隔，LIKE '%数据库%' 这类查询本质是逐行扫描字符串，哪怕字段有索引也基本失效。10 万行可能毫秒级，1000 万行就明显卡顿。
能优化的只有写法：
- 前缀匹配可用索引：
WHERE title LIKE 'MySQL%'→ 可走INDEX(title) - 固定长度姓名查可用
_：WHERE name LIKE '王__'（三字名），但注意：MySQL 中CHAR字段末尾空格会被忽略，LIKE '王 '可能意外匹配 - 真要支持任意位置中文关键词，别硬扛 LIKE —— 改用 MySQL 的
MATCH AGAINST（需全文索引）或 PostgreSQL 的to_tsvector+@@
搜索内容含 % 或 _ 时必须转义
用户搜“折扣率 95%”或“订单号 A_B2024”，这些字符在 LIKE 里是通配符，直接拼进 SQL 会导致逻辑错乱甚至报错。
正确做法是声明转义字符并显式转义：
-
WHERE comment LIKE '%95!%%' ESCAPE '!'→ 查含 “95%” 的评论 -
WHERE order_no LIKE 'A!_B2024' ESCAPE '!'→ 查 “A_B2024”，而非 “AxB2024”、“AyB2024” - 转义符选
!、\、#都可以，但必须确保它不出现在原始搜索词里 - 千万别用字符串替换（如把
%换成\%）却不加ESCAPE子句，数据库不会识别
NULL 值和大小写处理常被忽略
LIKE 不匹配 NULL，这是最隐蔽的漏查原因。比如 WHERE tag LIKE '%推荐%' 会跳过所有 tag IS NULL 的记录，而业务上往往需要它们也参与筛选。
大小写问题在中文虽不明显，但混合英文/数字时就暴露了：
- MySQL 默认不区分大小写（依赖 collation），但
WHERE LOWER(title) LIKE '%mysql%'会强制函数计算，索引失效 - PostgreSQL 默认区分，应改用
ILIKE：WHERE title ILIKE '%数据库%' - 安全写法是统一转换字段：
WHERE UPPER(name) LIKE UPPER('张%')，但仅限小表或已建函数索引场景
真正棘手的是简繁体、异体字、全角半角混杂——LIKE 本身不做归一化，靠它解决这类问题，相当于拿螺丝刀修电路板。该上全文检索时就别省那点配置时间。
