结论：用 like '%keyword%' 实现全字段子串匹配，但必须参数化拼接通配符、注意大小写敏感性（如用 lower() 统一）、对 % 和 _ 等特殊字符启用 escape 转义，且需知其无法走索引导致性能较差。
直接说结论：用 LIKE '%keyword%'，但必须加通配符、必须参数化、必须注意大小写和转义。
为什么 WHERE column = 'xxx' 查不到“包含”的记录
因为 = 是精确匹配，只返回字段值**完全等于**字符串的行。比如 productName = 'shirt' 不会命中 'polo shirt' 或 't-shirt' —— 它们不是同一个字符串。
要表达“字段里有这个词”，本质是子串匹配，SQL 里靠 LIKE + 通配符实现，不是靠等号。
-
%匹配零个或多个任意字符（最常用） -
_匹配恰好一个任意字符（少用，易误判） - 不加通配符的
LIKE 'abc'和= 'abc'行为一致，没意义
怎么写安全又有效的 LIKE 查询
错误写法："SELECT * FROM products WHERE name LIKE '$user_input'" —— 既没通配符，又拼接字符串，双重危险。
正确做法分两步：先在应用层加通配符，再交给预处理语句：
- PHP + PDO 示例：
$stmt = $pdo->prepare("SELECT * FROM products WHERE name LIKE ?"); $stmt->execute(["%{$search}%"]); - 通配符必须由代码拼接（
"%{$search}%"），不能写死在 SQL 字符串里 - 如果数据库字段存的是小写，建议统一转小写查询：
LOWER(name) LIKE LOWER(?)，避免大小写漏匹配 - MySQL 默认不区分大小写，但 PostgreSQL 和 SQL Server 默认区分，这点容易被忽略
遇到特殊字符（如 %、_、/）怎么办
当关键词本身含通配符（比如查字符串 p%attern），直接 LIKE '%p%attern%' 会被当成模式解析，结果错乱。
解决方案是用 ESCAPE 指定转义符：
-
WHERE net LIKE 'http%//%' ESCAPE ''—— 把%当作字面量%处理 -
WHERE path LIKE 'C:\temp\%' ESCAPE ''—— Windows 路径里的反斜杠需双写并声明 ESCAPE - 如果关键词来自用户，且你不确定是否含特殊字符，更稳妥的是改用正则（如 MySQL 的
REGEXP）或全文索引，而不是硬套LIKE
性能差？别怪 LIKE，先看有没有走索引
LIKE 'abc%' 可走前缀索引，LIKE '%abc%' 基本无法利用 B-Tree 索引，全表扫描是常态。
不是语法写错了，是设计上就慢。应对方式有限：
- 字段建了前缀索引？
LIKE 'abc%'有效，LIKE '%abc'无效 - 数据量大且高频模糊查？考虑
FULLTEXT索引（MySQL）或tsvector（PostgreSQL） - 纯内存查？把关键字段导出到 Redis 的集合或 Sorted Set 做前缀匹配
- 别试图用
OR (LIKE 'a%' OR LIKE '%b' OR LIKE '%c%')来凑逻辑——性能雪崩，可读性归零
真正难的从来不是怎么写那条 SQL，而是想清楚：这个“包含”查询是不是真该由数据库实时扛着做。
