sql中使用like操作符进行模糊查询，配合通配符%（匹配任意数量字符）和_（匹配单个字符），可灵活筛选文本数据；2. 基本语法为select 列名 from 表名 where 列名 like ‘模式字符串’，其中%用于前缀、后缀或包含匹配，_用于固定位置的单字符匹配；3. 通配符%在前（如’%关键词’）会导致全表扫描，性能较差，应尽量避免，可考虑使用全文搜索或trigram索引优化；4. 不同数据库对like的大小写敏感性不同，postgresql默认区分，mysql通常不区分，可通过lower()函数或ilike（postgresql）实现不区分大小写的查询；5. 搜索内容包含%或_时需使用escape子句指定转义字符，如like ‘%50%%’ escape ”；6. like不匹配null值，需结合or column is null处理；7. 对于大文本字段的高效搜索，应使用全文搜索（如mysql的match against、postgresql的tsvector）；8. 复杂模式匹配可使用正则表达式（如mysql的regexp、postgresql的~），但性能较低，应谨慎使用；9. 应根据场景选择合适工具：简单模糊查询用like，高性能文本搜索用全文搜索，复杂模式用正则表达式。
SQL中要进行模糊查询，
LIKE
操作符是你的首选，它配合通配符
%
（匹配任意数量的字符）和
_
（匹配单个字符），能让你灵活地筛选出符合特定模式的数据。这在搜索名字、地址或任何文本字段时都非常实用。
解决方案
使用
LIKE
进行模糊查询的基本语法是：
SELECT 列名 FROM 表名 WHERE 某个列 LIKE '模式字符串';
这里的“模式字符串”就是你定义模糊匹配规则的地方。
核心在于两个通配符：
%
：代表零个、一个或多个字符的任意序列。比如，
'王%'
会匹配所有以“王”开头的字符串；
'%国%'
会匹配所有包含“国”字的字符串；
'%张三'
则匹配所有以“张三”结尾的字符串。
_
：代表任意单个字符。如果你想找一个名字是“李X明”的人，就可以用
'李_明'
。
举个例子，如果你想从一个
users
表中找出所有名字包含“小”字的用户：
SELECT name, email FROM users WHERE name LIKE '%小%';
再比如，要找名字第二个字是“大”的用户：
SELECT name, email FROM users WHERE name LIKE '_大%';
记住，
LIKE
是区分大小写的，还是不区分大小写，这往往取决于你所使用的数据库系统及其配置。比如，MySQL默认通常不区分，而PostgreSQL默认是区分的。
LIKE
操作符中的通配符：
%
和
_
的实战用法
通配符的使用其实很有讲究，不仅仅是简单的放进去。我个人在使用中发现，理解它们的“贪婪”与“精确”特性，能帮助你更精准地构建查询。
%
的灵活应用：
前缀匹配：
'关键词%'
当你只记得一部分开头时，这非常有用。比如，查找所有“北京”开头的地址：
SELECT address FROM locations WHERE address LIKE '北京%';
这种方式在很多数据库系统里，如果
address
列有索引，并且索引类型合适，查询效率会相对较高，因为数据库可以利用索引进行“前缀查找”。
后缀匹配：
'%关键词'
如果你只记得结尾部分，比如找所有以“.com”结尾的邮箱：
SELECT email FROM users WHERE email LIKE '%.com';
这种查询，由于
%
在前，通常无法利用列上的常规索引，可能会导致全表扫描，在大表上性能会比较差。
包含匹配：
'%关键词%'
这是最常见的用法，只要字符串中包含某个子串即可。比如，查找所有描述中包含“解决方案”的产品：
SELECT product_name FROM products WHERE description LIKE '%解决方案%';
同样，由于前后都有
%
，这种查询通常也无法利用常规索引，性能问题会更突出。
_
的精确控制：
神采PromeAI
将涂鸦和照片转化为插画，将线稿转化为完整的上色稿。
97 查看详情 
_
虽然不如
%
常用，但在需要固定长度或特定位置匹配时，它就显得不可或缺了。
固定位置匹配：
'__关键词%'
例如，查找所有电话号码第三位是“8”的记录（假设电话号码都是固定长度）：
SELECT phone_number FROM contacts WHERE phone_number LIKE '__8%';
这比用
%
更精确，避免了匹配到其他位置的“8”。
结合使用：
LIKE
的强大之处在于可以组合使用
%
和
_
。比如，查找所有姓“张”且名字是两个字（共三个字）的人：
SELECT full_name FROM employees WHERE full_name LIKE '张__';
或者，查找所有以“A”开头，倒数第二个字符是“B”的编码：
SELECT code FROM items WHERE code LIKE 'A%B_';
这种组合使用，让你的模式匹配能力变得非常强大，可以应对各种复杂的模糊查询场景。
模糊查询的进阶技巧与潜在陷阱：效率与精度考量
LIKE
虽然好用，但在实际生产环境中，我遇到过不少因为不恰当使用它而引发的性能问题，以及一些需要注意的细节。
1. 大小写敏感性：这是个老生常谈但又容易被忽视的问题。不同的数据库系统对
LIKE
操作的大小写敏感性处理方式不一。
PostgreSQL 默认是区分大小写的。如果你想进行不区分大小写的模糊查询，可以使用
ILIKE
操作符（PostgreSQL特有），或者将查询字符串和列都转换为统一的大小写（
LOWER(column) LIKE LOWER('pattern')
）。MySQL 默认通常不区分大小写（取决于字符集和排序规则）。SQL Server 也取决于数据库或列的排序规则（Collation）。如果你需要强制不区分大小写，也可以使用
COLLATE
子句指定不区分大小写的排序规则。
我通常建议在应用程序层面统一处理大小写，或者在SQL中使用
LOWER()
或
UPPER()
函数，这样可以确保跨数据库的一致性，虽然这会牺牲一部分性能，因为它阻止了索引的使用。
2. 性能陷阱：前导通配符（Leading Wildcard）这是
LIKE
最大的性能杀手。当你的模式以
%
开头时（例如
'%关键词'
或
'%关键词%'
），数据库几乎无法使用该列上的任何常规B-tree索引。它不得不扫描整个表，逐行检查是否匹配。对于包含数百万甚至数十亿行的大表来说，这会是灾难性的。
替代方案：全文搜索（Full-Text Search）： 如果你的主要需求是高效地在大文本字段中搜索关键词，并且需要支持词干、同义词、相关性排序等高级功能，那么数据库自带的全文搜索功能（如MySQL的
MATCH AGAINST
，PostgreSQL的
tsvector/tsquery
，SQL Server的
CONTAINS
）是更好的选择。它们通常会创建专门的倒排索引，查询速度飞快。Trigram索引： 某些数据库（如PostgreSQL）支持trigram索引（
pg_trgm
扩展），可以显著加速
%keyword%
这种包含查询。它通过索引字符串中所有三个字符的组合来工作。应用层处理： 有时候，如果数据量不是特别大，或者查询频率不高，将数据拉取到应用层进行内存匹配也是一种选择，但这通常不推荐，因为会增加网络I/O和应用服务器的负载。
3. 转义特殊字符：
ESCAPE
子句如果你需要搜索的字符串本身就包含
%
或
_
这两个通配符，那么直接写在
LIKE
模式中会被误认为是通配符。这时就需要用到
ESCAPE
子句来指定一个转义字符。
例如，你想查找所有包含字符串
'50%'
的产品编码：
SELECT product_code FROM products WHERE product_code LIKE '%50%%' ESCAPE '';
这里，
被指定为转义字符，所以
%
就被解释为字面意义上的
%
。你可以选择任何一个不常出现在你数据中的字符作为转义字符。
4.
NULL
值的处理：
LIKE
操作符不会匹配
NULL
值。如果你有一个列中包含
NULL
，并且你期望它们也能参与到模糊查询中，那你就需要额外处理，比如使用
OR column IS NULL
，或者在数据录入时就避免
NULL
，用空字符串代替（这取决于你的业务逻辑和数据模型）。
-- 查找名字包含'李'或者名字为NULL的用户SELECT name FROM users WHERE name LIKE '%李%' OR name IS NULL;
在我看来，理解这些细节和潜在问题，远比仅仅知道
LIKE
的语法来得重要。它能让你写出更健壮、更高效的SQL查询。
LIKE
的替代方案：何时考虑全文搜索或正则表达式？
虽然
LIKE
在SQL模糊查询中占据主导地位，但它并非万能药。在某些场景下，它的局限性会变得很明显，这时就需要考虑更专业的工具。
1. 全文搜索（Full-Text Search, FTS）：当你的模糊查询需求超越了简单的模式匹配，进入到“自然语言搜索”的范畴时，全文搜索就是你的不二之选。
适用场景：在长篇文章、产品描述、评论等大文本字段中查找关键词。需要考虑词形变化（例如，搜索“run”也能匹配“running”、“ran”）。需要排除常见词（停用词，如“的”、“是”）。需要根据匹配相关性进行结果排序。对查询性能有极高要求，尤其是在海量文本数据中。工作原理： 全文搜索通常通过构建“倒排索引”来实现。这个索引会记录每个词在哪些文档中出现，以及出现的位置和频率，从而实现闪电般的查询速度和高级的语义匹配。主流数据库实现：MySQL：
MATCH (column_list) AGAINST ('search_string' IN MODE)
PostgreSQL：
to_tsvector()
和
to_tsquery()
函数，配合
@@
操作符。SQL Server：
CONTAINS()
,
FREETEXT()
,
CONTAINSTABLE()
,
FREETEXTTABLE()
。我的看法： 如果你发现自己频繁地用
LIKE '%keyword%'
去搜索大段文本，并且性能开始成为瓶颈，那么投入时间学习和部署数据库的全文搜索功能绝对是值得的。它能提供远超
LIKE
的搜索能力和效率。
2. 正则表达式（Regular Expressions）：当你的模式匹配需求变得非常复杂，超出了
%
和
_
所能表达的范围时，正则表达式就登场了。它能让你定义极其精细的匹配规则，比如验证邮箱格式、提取特定格式的电话号码、查找满足特定字符序列的文本等。
适用场景：需要匹配特定字符集（例如，只包含数字的字符串）。需要匹配重复模式（例如，连续出现三次的数字）。需要进行更复杂的字符位置和组匹配。验证数据格式（例如，邮政编码、身份证号）。主流数据库实现：MySQL：
REGEXP
或
RLIKE
操作符。PostgreSQL：
~
（区分大小写匹配），
~*
（不区分大小写匹配），
SIMILAR TO
（虽然功能不如
~
强大，但更接近SQL标准）。Oracle：
REGEXP_LIKE()
函数。SQL Server： 原生支持较弱，通常需要结合
PATINDEX
和
LIKE
的组合，或者通过CLR集成自定义函数。我的看法： 正则表达式功能强大，但学习曲线相对陡峭，而且通常比
LIKE
和全文搜索的性能要差，因为它通常也无法利用索引。所以，我倾向于在
LIKE
无法满足的、且性能要求不那么极致的复杂模式匹配场景下才考虑使用正则表达式。如果能用
LIKE
解决，就尽量用
LIKE
；如果性能是关键，且是文本搜索，就考虑全文搜索。
总而言之，
LIKE
是SQL模糊查询的基石，简单易用，但它有其局限性。了解这些替代方案，并在合适的场景选择合适的工具，才能真正写出高效且满足需求的SQL查询。
以上就是sql怎样使用like进行模糊查询 sql模糊查询与like用法的实用技巧的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/861678.html
微信扫一扫 
支付宝扫一扫 
