SQL模糊匹配查询：LIKE通配符使用规则与注意事项

在SQL中进行数据检索时，精确匹配（例如 =）只能找到完全一致的文本。为了查找包含特定字符、具备固定格式或前后缀已知的数据，SQL提供了 LIKE 操作符与通配符机制。本文将讲解百分号 % 与下划线 _ 的使用规则、特殊字符的转义技巧，并通过对比与索引分析，说明在生产环境中编写高效模糊查询的注意事项。

一、LIKE模糊查询的基础原理与匹配流程

LIKE 是SQL中专用于字符串模式匹配的谓词。其工作机制是将目标字段中的文本与指定的模式字符串进行逐字符比对。如果字段中的字符序列符合通配符定义的排布规则，表达式即返回真值（TRUE），对应行被包含在查询结果集中。

为了理解查询引擎如何处理一个模式，我们可以通过匹配流程直观地看到字符比对的判定链条：

图1：SQL LIKE 模式匹配的执行判断步骤

二、两大核心通配符的使用规则

标准SQL为 LIKE 定义了两个核心通配符：百分号（%）和下划线（_）。它们在字符数量界定和位置约束上有严格区别。

1. 百分号（%）：匹配任意个字符

% 代表零个、一个或多个连续的任意字符。它不对匹配的字符长度做任何限制。

• 前缀匹配（'abc%'）：匹配以 "abc" 开头的字符串，如 "abc"、"abcd"、"abc-123"。
• 后缀匹配（'%xyz'）：匹配以 "xyz" 结尾的字符串，如 "xyz"、"123xyz"。
• 包含匹配（'%test%'）：匹配任何包含 "test" 的字符串，位置不限。

2. 下划线（_）：匹配恰好一个字符

_ 代表一个且仅一个任意字符。下划线所处的位置必须有字符存在，且必须完全对齐数量。两个连续的下划线 __ 则表示恰好匹配两个字符。

图2：% 与 _ 在长度约束与匹配灵活性上的核心特征对比

3. 实际语法示例

假设存在一张员工信息表 employees，包含字段 emp_name 与 phone：

-- 示例1：查询所有以 "张" 开头的员工姓名（姓张且名长度不限）
SELECT emp_name, phone 
FROM employees 
WHERE emp_name LIKE '张%';

-- 示例2：查询所有姓 "张" 且全名正好为两个字的员工姓名
SELECT emp_name, phone 
FROM employees 
WHERE emp_name LIKE '张_';

-- 示例3：查询手机号以 "138" 开头、后跟任意8位数字的记录
SELECT emp_name, phone 
FROM employees 
WHERE phone LIKE '138________';

三、两种查询方式的差异：精确匹配与模糊匹配

在SQL查询设计中，开发者常面临选择 = 还是 LIKE。在相同的数据集和查询目标下，两者的执行机制和设计目标存在显著差异：

这种差异之所以重要，是因为滥用 LIKE 代替 = 会导致数据库优化器在规划执行路径时采取保守策略。如果明确已知完整字符串，应始终优先使用 =。

四、转义处理：如何匹配真正的“%”和“_”字符？

当查询的内容本身包含百分号或下划线时（例如查找折扣字符串 '20%' 或文件命名 'order_01.csv'），直接写入 LIKE '%20%%' 会导致解析混乱。

解决方式是通过 ESCAPE 关键字定义转义字符。任何跟随在转义字符后面的 % 或 _ 都会被视为普通字符。

-- 示例：查找折扣字段中包含字面量 "20%" 的商品记录
-- 使用斜杠 '/' 作为自定义转义字符
SELECT product_id, discount_label 
FROM products 
WHERE discount_label LIKE '%20/%%' ESCAPE '/';

-- 示例：查找订单编号以 "ORD_" 开头的单据
SELECT order_no 
FROM orders 
WHERE order_no LIKE 'ORD/_%' ESCAPE '/';

五、LIKE 查询的索引生效与失效机制

在生产环境中，使用 LIKE 最容易导致系统告警的问题就是全表扫描（Full Table Scan）。

关系型数据库大多使用 B+树 作为普通列索引的数据结构。B+树索引是按照键值的从左到右严格排序的。因此，索引查找必须依赖已知的前缀。如果模式字符串以通配符开头，B+树将无法确定起步搜索分支，只能逐页读取整张表的所有数据。

图3：前缀固定与左侧通配符对B+树索引调用的不同影响

六、生产环境使用注意事项与优化清单

为了避免因为模糊匹配带来性能隐患或业务逻辑异常，在编写 SQL 语句时需要遵循以下准则：

1. 谨防左侧模糊查询：形如 LIKE '%keyword' 或 LIKE '%keyword%' 的查询会导致索引失效。当数据量达到数十万乃至数百万级别时，容易造成磁盘I/O飙升。对于高频的大文本搜索，应改用专用全文检索引擎（如 Elasticsearch）或数据库内置全文索引（如 MySQL Fulltext Index）。
2. 注意 NULL 值的排他性：如果字段值为 NULL，无论是 LIKE '%' 还是 NOT LIKE '%'，其判断结果均为 UNKNOWN，不会被选入结果集。若需要包含空值记录，必须显式加上 OR col_name IS NULL。
3. 大小写敏感性规则：LIKE 是否区分大小写取决于数据库类型及字段的排序规则（Collation）。例如，MySQL 默认的 utf8mb4_general_ci（ci = Case Insensitive）不区分大小写，而 Oracle 或 PostgreSQL 默认严格区分大小写（PostgreSQL 可使用 ILIKE 执行不敏感查询）。
4. 巧用反向索引解决后缀匹配：如果业务需求固定为匹配后缀（例如查找所有 '.org' 结尾的域名），可以新增一个存储反转字符串的列并建立索引。查询时将输入条件反转为 LIKE 'gro.%'，从而把不可命中索引的后缀查询转换为前缀查询。

图4：LIKE 通配符检索规则与生产规范全景总结

掌握通配符的长度属性、规范使用 ESCAPE 转义，并在编写查询条件时刻意保留固定的前缀常量，是保证 SQL 模糊查询兼顾灵活性与查询性能的关键基石。