sql中like不能直接匹配子查询多行结果，因其为标量操作符，要求右操作数为单值；多行返回会报错，可用exists+like或join+like实现模糊匹配，但前导%导致索引失效。
SQL中不能直接用 LIKE 匹配子查询返回的多行结果——它只接受单值右侧操作数，否则必然报错 Subquery returns more than 1 row 或 Operand should contain 1 column(s)。
为什么 WHERE col LIKE (SELECT pattern FROM t) 会失败
根本原因是 LIKE 是标量比较操作符，语义上要求左右两侧都为单值。子查询若返回多行（哪怕只多一行），数据库就无法决定“拿哪一行去比”，直接拒绝执行。
- MySQL/PostgreSQL/SQL Server 都会明确报错，不是静默跳过
- 即使子查询恰好只返回一行，也只是做一次单次匹配，不是“对每个 pattern 尝试一遍”
-
col LIKE IN (SELECT ...)语法非法，SQL 标准不支持这种组合 - 想靠加括号、改写成
(col LIKE ... OR col LIKE ...)手动展开？那得应用层拼 SQL，极易引入SQL 注入
用 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转义或应用层预处理 - 性能注意：
LIKE '%xxx%'无法走索引，若search_patterns行数多，可能触发嵌套循环扫描，响应变慢 - MySQL 5.7+、PostgreSQL、SQL Server 全支持，无需额外版本要求
用 JOIN + LIKE 获取匹配详情并去重
当你不仅想知道“是否匹配”，还要知道“匹配了哪个 pattern”、或需要按 pattern 聚合统计时，JOIN 更直观。
SELECT DISTINCT u.*
FROM users u
INNER JOIN search_patterns p
ON u.username LIKE CONCAT('%', p.pattern, '%');
- 必须加
DISTINCT：一个 user 可能同时匹配多个 pattern，否则结果重复 - 可扩展性强：比如
SELECT u.id, u.username, p.pattern就能看清具体匹配关系 - 相比
EXISTS，连接本身有开销，但现代优化器通常能合理处理 - SQLite 不支持
ON中用LIKE关联列（会报no such column），务必改用WHERE显式写法
前导 % 是性能硬伤，别指望索引救场
无论用 EXISTS 还是 JOIN，只要 LIKE 模式以 % 开头（例如 '%abc' 或 '%abc%'），B-Tree 索引就完全失效，只能全表扫描。
- 唯一能走索引的模糊形式是前缀匹配：
col LIKE 'abc%'—— 这时可建普通索引加速 - 业务上真要高频查“包含某词”，别硬扛
LIKE，考虑FULLTEXT索引（MySQL）、tsvector（PostgreSQL）或外部搜索引擎 - 如果 pattern 来自用户输入，且允许“开头匹配”，优先引导用户用
abc%而非%abc%，延迟能差一个数量级
真正动态的关键词列表，别在 SQL 层拼接；子查询只是中介，核心逻辑应在应用层控制输入、转义、分页和缓存。否则，一个没过滤的恶意 pattern 就可能拖垮整张表。
