SQL嵌套查询中LIKE不能匹配子查询结果集，仅支持单值比较；应改用EXISTS+LIKE或JOIN+LIKE实现多关键词模糊匹配，避免SQL注入。
直接说结论：SQL嵌套查询中不能把 LIKE 当作“匹配整个子查询结果集”的工具用——它只作用于单个字符串值，不是集合操作符。想实现“主查询某字段是否模糊匹配子查询返回的多个关键词”，得换思路。
子查询返回多行时，LIKE 会报错或行为异常
比如写成这样：
SELECT * FROM users WHERE username LIKE (SELECT pattern FROM search_patterns);
只要 search_patterns 表返回超过一行，MySQL/PostgreSQL 都会报错：Subquery returns more than 1 row。即使只返回一行，它也只是拿 username 去匹配那一个 pattern，不是“对每个 pattern 都试一遍”。
- 错误现象：
Operand should contain 1 column(s)或Single-row subquery returns more than one row - 根本原因：
LIKE是标量比较操作符，左侧是单值，右侧也必须是单值 - 别指望加
IN能救场：username LIKE IN (SELECT pattern...)语法不合法
用 EXISTS + LIKE 实现“字段匹配任意一个动态关键词”
这是最常用、兼容性最好的方案：把子查询包进 EXISTS，在子查询里做 LIKE 判断，让数据库逐行检查是否存在匹配项。
SELECT u.* FROM users u
WHERE EXISTS (
SELECT 1 FROM search_patterns p
WHERE u.username LIKE CONCAT('%', p.pattern, '%')
);
- 适用场景：查出所有用户名包含任一关键词的用户（关键词存在另一张表里）
- 注意
p.pattern本身不能含通配符；如果需要支持%或_，得提前转义或改用ESCAPE - 性能影响：若
search_patterns行数多，可能触发嵌套循环；加索引没用，因为LIKE '%xxx%'无法走索引
用 JOIN + LIKE 并去重，适合需要关联信息的场景
当不仅要判断“是否匹配”，还要拿到匹配了哪个 pattern、或做后续聚合时，JOIN 更直观：
SELECT DISTINCT u.*
FROM users u
INNER JOIN search_patterns p ON u.username LIKE CONCAT('%', p.pattern, '%');
- 比
EXISTS多一次连接开销，但能SELECT p.pattern查看具体匹配项 -
DISTINCT必须加——一个 user 可能匹配多个 pattern，否则会重复出现 - PostgreSQL 用户可考虑
UNIQUE约束或LATERAL子查询替代，但 MySQL 8.0+ 才支持LATERAL
真正动态拼接关键词？别在 SQL 层做，交给应用层
如果关键词来自 HTTP 参数、配置文件等运行时输入，且数量不定（比如前端传了 3 个关键词），硬要在纯 SQL 里拼成 OR username LIKE '%a%' OR username LIKE '%b%' OR ... 不现实——SQL 不支持动态生成任意长度的 OR 链。
- 正确做法：应用代码（Java/Python/Node.js）组装好完整
WHERE条件，再用参数化方式执行（如 MyBatis 的CONCAT，或 JDBC 的PreparedStatement） - 绝对避免：用字符串拼接把用户输入直接塞进 SQL，这是
SQL injection高危路径 - 容易被忽略的点：哪怕用了
CONCAT('%', #{keyword}, '%')，如果#{keyword}本身含%或_，仍可能误匹配；必要时需用ESCAPE指定转义符
