使用 LIKE '%keyword%' 可实现不限位置的全字段模糊匹配，但性能较差且需注意大小写敏感性、SQL注入防护及多字段匹配需分别书写条件。
直接用 LIKE '%keyword%' 就能实现不限位置的全字段模糊匹配，但要注意性能和语义细节。
基本写法：通配符放两端
在 WHERE 子句中对目标字段使用 LIKE '%keyword%'，表示匹配任意位置包含该关键词的记录：
-
SELECT * FROM users WHERE name LIKE '%明%';—— 匹配“张明”“李晓明”“陈光明”等 - 注意：
%是通配符，代表零个或多个任意字符；下划线_代表单个任意字符（不常用在此场景） - 区分大小写取决于数据库配置（如 MySQL 默认不区分，PostgreSQL 默认区分），必要时加
ILIKE（PostgreSQL）或用LOWER()统一转换
确保匹配整字段，而非仅前缀或后缀
容易混淆的是：LIKE 'keyword%' 只匹配开头，LIKE '%keyword' 只匹配结尾。要真正“不限位置”，必须两端都加 %：
- ✅ 正确：
content LIKE '%error%'→ 匹配 “System error occurred”、“An error was found”、“debug: no error” - ❌ 错误：
content LIKE 'error%'→ 漏掉 “network error” 这类关键词在中间或末尾的情况
提升可读性与安全性：参数化 + 明确字段
避免拼接字符串防止 SQL 注入，尤其在应用层调用时：
- 推荐用预处理语句（如 Python 的
cursor.execute("WHERE title LIKE %s", ('%' + keyword + '%',))） - 明确指定字段名，不要写
SELECT * LIKE '%x%'（语法错误），模糊匹配只能作用于具体列 - 若需多字段同时匹配，需分别写条件：
WHERE title LIKE '%kw%' OR content LIKE '%kw%'
性能提醒：全模糊查可能很慢
LIKE '%keyword%' 无法有效使用常规 B-Tree 索引（因左端有 %），大数据量时易成全表扫描：
- 小表或低频查询影响不大；高频或大表建议补充全文索引（如 MySQL 的
FULLTEXT，PostgreSQL 的tsvector） - 若业务允许，优先考虑前缀匹配（
LIKE 'keyword%'），它能走索引 - 测试执行计划（
EXPLAIN）确认是否用到索引
