在SQL开发中,LIKE模糊匹配是最常用的查询手段之一。然而,当需要同时匹配多个模式(如查找包含"苹果"或"香蕉"的记录)时,LIKE本身并不支持直接传入多个值。开发者需要借助不同的技术手段来实现多值LIKE查询。本文将系统梳理五种主流方案,分析各自的语法特点、适用场景及性能表现。
这是最基础、兼容性最好的方案。通过多个LIKE条件用OR连接,实现"匹配任意一个模式"的效果。
SELECT * FROM products
WHERE product_name LIKE '%苹果%'
OR product_name LIKE '%香蕉%'
OR product_name LIKE '%橙子%';如果需要同时满足多个模式(逻辑与),则将OR替换为AND即可。该方案的核心要点如下:
优点:所有数据库系统均支持,语法简单直观,无需额外扩展。
缺点:当匹配模式数量较多时,SQL语句会变得冗长,且每个LIKE条件都可能导致全表扫描,性能随条件数量线性下降。
注意事项:当OR条件与其他AND条件混合使用时,必须用括号明确优先级,否则AND会优先于OR执行,导致逻辑错误。
MySQL的REGEXP(或RLIKE)和Oracle的REGEXP_LIKE函数支持正则语法,可以用一个表达式替代多个LIKE条件。
-- MySQL写法
SELECT * FROM products
WHERE product_name REGEXP '苹果|香蕉|橙子';
-- Oracle写法
SELECT * FROM products
WHERE REGEXP_LIKE(product_name, '苹果|香蕉|橙子');该方案的核心要点如下:
优点:一条语句即可完成多模式匹配,代码简洁;正则表达式功能强大,支持更复杂的模式(如前缀、后缀、字符集等)。
缺点:正则匹配的计算开销通常高于LIKE,且不同数据库的正则语法存在差异,可移植性较差。
适用场景:匹配模式数量较多、模式之间为"或"关系、且数据库支持正则函数时优先考虑。
当匹配模式存储在另一张表中(如关键词表)时,可以通过EXISTS子查询实现动态多值LIKE匹配。这是处理动态关键词列表最通用、最安全的方案。
SELECT u.* FROM users u
WHERE EXISTS (
SELECT 1 FROM search_patterns p
WHERE u.username LIKE CONCAT('%', p.keyword, '%')
);该方案的核心要点如下:
优点:匹配模式完全由数据驱动,无需在SQL中硬编码;兼容MySQL 5.7+、PostgreSQL、SQL Server等主流数据库;天然防止SQL注入,因为关键词来自表数据而非用户拼接。
缺点:若关键词表行数较多,可能触发嵌套循环扫描,性能需要关注。
适用场景:关键词列表存储在数据库中、需要动态维护的场景,如搜索标签匹配、敏感词过滤等。
与EXISTS类似,JOIN方案将主表与模式表进行关联,不仅能判断是否匹配,还能获取具体匹配了哪个模式。
SELECT DISTINCT u.*
FROM users u
JOIN search_patterns p
ON u.username LIKE CONCAT('%', p.keyword, '%');该方案的核心要点如下:
优点:通过扩展SELECT字段(如SELECT u.*, p.keyword),可以清楚看到每条记录具体匹配了哪个关键词,便于调试和统计;可扩展性强,支持按模式聚合统计。
缺点:必须使用DISTINCT去重,因为一条记录可能匹配多个模式,否则结果会出现重复行;JOIN本身的开销略高于EXISTS。
适用场景:需要知道"匹配了哪个关键词"、或需要按关键词分组统计的场景。
当多个匹配模式具有共同的字符结构时,可以利用LIKE的通配符字符集语法进行简写。例如查找以"emp1"或"emp3"开头的记录,可以合并为一个模式。
SELECT * FROM employees
WHERE employee_id LIKE 'emp[13]%';其中[13]表示匹配字符"1"或"3"。该方案的核心要点如下:
优点:语法极其简洁,且由于是前缀匹配(LIKE 'emp[13]%'),可以利用B-Tree索引,性能远优于LIKE '%xxx%'。
缺点:适用范围有限,仅当多个模式具有相同的字符位置和结构时才能合并;该语法主要在SQL Server中支持,MySQL不支持方括号字符集语法(MySQL需用REGEXP替代)。
适用场景:模式具有规律性前缀或固定位置字符差异的场景,如编号、编码类字段的批量匹配。
![]()
五种LIKE多值查询方案各有侧重:OR组合是通用基础方案,适合少量静态条件;正则表达式适合模式较多且为"或"关系的场景;EXISTS子查询适合关键词动态存储在表中的场景,安全性最高;JOIN方案在需要获取匹配详情时更具优势;通配符字符集简写则在模式具有规律性时最为高效。实际开发中,应根据匹配模式的数量、是否动态、数据库类型以及性能要求进行综合选择。对于高频、大数据量的模糊搜索场景,建议进一步考虑全文索引(FULLTEXT)或外部搜索引擎(如Elasticsearch)来替代LIKE,从根本上解决性能瓶颈。
声明:所有来源为“聚合数据”的内容信息,未经本网许可,不得转载!如对内容有异议或投诉,请与我们联系。邮箱:marketing@think-land.com
通过手机号码查询近3个月总停机次数标签信息,统计近3个月内停机的次数。
通过手机号查询判断该号码实名用户年龄区间标签信息。
通过三网运营商手机号码和指定月份,查询号码近3个月话费消费区间标签详情及评分。
通过车架号或车牌号查询车辆是否为营运车辆
通过车架号查询车辆的如品牌名称、车系名称、车型、排量、排放标准、外形尺寸、轮胎规格、变速器类型、公告号、轴距等等详细信息