在数据库查询中，精确匹配往往不能满足业务需求。例如运营人员只记得客户姓氏，产品经理想找出所有名称带“旗舰”的商品，这类场景都需要模糊匹配。SQL提供的LIKE操作符配合通配符，正是解决这类问题的标准方案。本文将从通配符基础用法讲起，逐步扩展到多条件组合查询和性能优化，帮助你全面掌握模糊查询的技巧。
LIKE通配符有哪些？三种基础用法详解
LIKE子句支持两种核心通配符，理解它们的含义是写对模糊查询的第一步。第一种是百分号%，表示匹配任意长度的字符串，包括零个字符；第二种是下划线_，表示匹配任意单个字符，且必须恰好一个。
例如查询姓氏为“张”的所有员工，可以写name LIKE '张%'，这里的百分号代表“张”字后面的任意内容，无论后面跟几个字都能匹配。而如果想查询姓名恰好为三个字且姓张的员工，则应写成name LIKE '张__'，两个下划线精确限定后面还有两个字符。
此外还有一个容易忽略的问题：如果待查询的内容本身包含百分号或下划线，比如查找文件名为“100%完成度.txt”的记录，直接写LIKE '100%'会在百分号处被当作通配符解析。此时需要使用ESCAPE子句指定转义字符。
-- 示例表：employees(id, name, phone, email) -- 1. 前缀匹配：查询所有姓张的员工 SELECT * FROM employees WHERE name LIKE '张%'; -- 2. 任意位置匹配：查询姓名中包含“明”的员工 SELECT * FROM employees WHERE name LIKE '%明%'; -- 4. 查询手机号第二位是3的记录（首位任意） SELECT * FROM employees WHERE phone LIKE '_3%'; -- 5. 转义特殊字符：查询文件名包含100%的记录 SELECT * FROM files WHERE file_name LIKE '%100!%%' ESCAPE '!';
上面最后一条语句中，感叹号被声明为转义字符，!%表示真正的百分号字面量，前后两个%仍是通配符。这个细节在处理用户输入时尤其重要，否则可能出现查询范围失控的安全隐患。
多条件与反向匹配：NOT LIKE和组合查询的写法
实际业务中，单一条件往往不够用。比如要求姓名包含“明”且邮箱以@ipipp.com结尾，就需要用AND把两个LIKE条件连接起来。多个模糊条件之间也可以灵活组合OR，实现“命中任意一个关键词即可”的效果。
反向匹配同样常见。例如统计所有不含“实习生”字样的员工，可以写WHERE position NOT LIKE '%实习生%'。需要注意NULL值的陷阱：如果某条记录的对应字段为NULL，无论LIKE还是NOT LIKE都返回未知结果，该行不会出现在结果集中，必要时需要用IFNULL或IS NULL额外处理。
-- 组合条件：姓名含“明”且邮箱以 @ipipp.com 结尾 SELECT name, email FROM employees WHERE name LIKE '%明%' AND email LIKE '%@ipipp.com'; -- OR组合：商品名包含“旗舰”或“Pro” SELECT product_name, price FROM products WHERE product_name LIKE '%旗舰%' OR product_name LIKE '%Pro%'; -- 反向匹配并处理NULL SELECT name FROM employees WHERE (position NOT LIKE '%实习生%' OR position IS NULL);
当关键词来自用户输入时，强烈建议在应用层做好参数校验和通配符转义，避免用户输入%导致查询条件被篡改，这也是防范SQL注入的一个环节。推荐使用预编译语句传递参数，而不是直接拼接字符串。
LIKE查询为什么慢？三种优化方案提升检索效率
很多开发者发现LIKE查询在大表上非常慢，根本原因在于索引失效。B+树索引按左前缀有序存储，而'%关键词'这种前置通配符的写法让数据库无法利用索引有序性定位，只能逐行扫描全表。数据量达到百万级时，响应时间会从毫秒级恶化到数秒甚至更久。
第一种优化思路是尽量使用前缀匹配'关键词%'。这种写法可以直接走普通索引，效率与等值查询相差不大。如果业务允许，把“任意位置搜索”改为“按前缀搜索”是最省成本的改造方案。可以通过EXPLAIN查看执行计划确认是否命中索引。
第二种方案是用内置函数替代。MySQL中的INSTR(name, '关键词') > 0和LOCATE('关键词', name) > 0都能实现包含匹配，虽然它们本身也不会让普通索引生效，但语义更清晰，且在配合函数索引或生成列时更灵活。
第三种方案是针对大文本检索引入全文索引。MySQL的FULLTEXT索引配合MATCH ... AGAINST语法，专门为关键词检索设计，性能远超LIKE扫描。此外，当数据规模极大且搜索是核心功能时，可以考虑将数据同步到Elasticsearch等专门的搜索引擎，由它承担模糊检索职责，数据库只做精确查询。
-- 方案一：前缀匹配，可命中name上的索引
SELECT id, name FROM employees WHERE name LIKE '张%';
-- 方案二：使用INSTR实现包含匹配
SELECT id, name FROM employees WHERE INSTR(name, '明') > 0;
-- 方案三：创建全文索引并检索
ALTER TABLE articles ADD FULLTEXT INDEX ft_content(content);
SELECT id, title FROM articles
WHERE MATCH(content) AGAINST('数据库优化' IN NATURAL LANGUAGE MODE);
-- 验证执行计划，观察key列是否使用了索引
EXPLAIN SELECT * FROM employees WHERE name LIKE '张%';
综合来看，LIKE适合中小数据量的灵活查询，全文索引适合内容检索场景，搜索引擎方案适合高并发大表。选型时应先评估数据规模和查询频率，再决定采用哪种方案，避免盲目为所有模糊查询加索引反而拖慢写入性能。
常见错误与最佳实践总结
初学者最容易犯的错误有三类：一是混淆%和_的语义，导致匹配位数不对；二是忘记转义用户输入中的通配符，造成查询条件被扩大；三是对NULL字段使用NOT LIKE却发现结果缺失，排查半天才发现是NULL三值逻辑的问题。
建议在团队规范中明确几条约定：涉及用户输入的模糊查询必须走预编译参数；通配符转义统一封装为工具函数；大表上的模糊查询必须经过EXPLAIN评审；对包含类查询优先评估全文索引的可行性。养成这些习惯后，LIKE既能保持简洁易读，又不会成为系统的性能瓶颈。