MySQL LIKE模糊查询语法与使用方法详解

时间：2026-08-18 06:27

MySQL 中使用 LIKE 查不到包含空格或特殊字符的字段，通常是因为 LIKE 会按字符逐个匹配，空格、制表符和不可见字符也会参与比较；建议结合 HEX() 查看真实字节内容，并通过 TRIM() 清理字段，必要时使用函数索引进行优化。LIKE 查询为什么查不到带空格或特殊字符的字段在 MyS

MySQL 中使用 LIKE 查不到包含空格或特殊字符的字段，通常是因为 LIKE 会按字符逐个匹配，空格、制表符和不可见字符也会参与比较；建议结合 HEX() 查看真实字节内容，并通过 TRIM() 清理字段，必要时使用函数索引进行优化。

如何使用MySQL LIKE进行模糊查询

LIKE 查询为什么查不到带空格或特殊字符的字段

在 MySQL 里，LIKE 默认会按照字符逐个进行匹配。也就是说，空格、制表符、不可见字符（例如 r、n）都会被纳入匹配条件中。如果你写了 name LIKE '%张%' 却依然查不到“张三”（中间含空格），那问题通常不在 SQL 语句本身，而在于字段实际保存了前后空格，或混入了隐藏字符。

实操建议：

先执行 SELECT HEX(name), LENGTH(name) FROM user WHERE id = 123; 检查字段的真实字节内容，HEX() 可以直接显示空格（20）、换行（0A）等特殊字符
查询前先统一清理字段内容：可使用 TRIM(name) LIKE '%张%'，也可以在建表时通过 GENERATED COLUMN 提前做标准化处理
尽量避免在 LIKE 左侧使用函数（例如 TRIM(name)），否则通常无法命中索引，除非你使用的是 MySQL 8.0+ 的函数索引

LIKE 前导通配符（%abc）为什么慢得像全表扫描

当 LIKE 以 % 开头时（例如 WHERE title LIKE '%error%'），MySQL 无法利用 B+ 树索引的有序特性，只能对整张表逐行扫描。因此即使字段上已经建立索引，查询性能也往往接近全表扫描。

实操建议：

能写成 LIKE 'abc%' 就不要使用 '%abc' 或 '%abc%'；前者通常可以走索引，后两者基本不能利用普通索引
如果业务必须支持中间模糊匹配，可以考虑全文索引：ALTER TABLE log ADD FULLTEXT(title);，然后配合 MATCH(title) AGAINST('error' IN NATURAL LANGUAGE MODE) 使用
对于短文本且高频的模糊搜索，也可以考虑 REGEXP，但其性能通常更差，更适合低并发或数据量较小的场景

中文模糊搜索遇到乱码或查不到字

这类问题的根本原因通常不在 LIKE 本身，而在于字符集设置不一致：客户端、连接、表、字段这四层只要有任意一层仍然使用 latin1 或 utf8（非 utf8mb4），中文内容就可能被存成问号或乱码，最终导致 MySQL 模糊查询失败。

实操建议：

先检查当前连接字符集：执行 SHOW VARIABLES LIKE 'character_set%';，确认 character_set_client、character_set_connection、character_set_results 都是 utf8mb4
建表时明确指定字符集和排序规则：CREATE TABLE t (name VARCHAR(100) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci);
如果历史数据已经出现乱码，仅执行 ALTER TABLE t CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; 可能并不能彻底解决，通常需要先导出原始数据再重新导入

ESCAPE 自定义转义符的典型误用

如果待匹配的字符串本身就包含 % 或 _（例如路径 /user%20profile），那么 ESCAPE 往往不能省略。这类 MySQL LIKE 查询场景非常容易出错：很多人会写成 LIKE '/user%20profile' ESCAPE ''，结果不是直接报错，就是始终匹配不到数据。原因就在于反斜杠进入 SQL 字符串后，还要先经过 MySQL 字符串解析，相当于被处理了两次。

实操建议：