子查询中用LIKE+OR实现多条件模糊匹配是任一条件成立即返回，非同时满足；需用AND连接才表示“同时包含多个关键词”，且推荐用CASE WHEN打分排序，避免全表扫描。
子查询里用 LIKE + OR 实现多条件模糊匹配
直接在子查询的 WHERE 中堆多个 LIKE 条件，是最常见也最容易出错的做法。比如想查同时匹配“北京”或“朝阳”或“望京”的地址，写成：
SELECT * FROM users WHERE id IN (SELECT id FROM addresses WHERE addr LIKE '%北京%' OR addr LIKE '%朝阳%' OR addr LIKE '%望京%')但要注意：这种写法会把任意满足其一的记录都拉进来，不是“多条件同时成立”，而是“任一条件成立”。真要“同时包含多个关键词”，得用多个
AND 连接：SELECT id FROM addresses WHERE addr LIKE '%北京%' AND addr LIKE '%朝阳%'否则打分排序就失去意义——你根本不知道哪条记录覆盖了几个关键词。
用 CASE WHEN 在子查询中动态打分
模糊匹配后要排序，光靠 IN 或 EXISTS 不行，必须把匹配强度算出来。推荐在子查询里用 CASE WHEN 给每条记录打分，再按分数排序。例如：
SELECT u.*, s.score FROM users u INNER JOIN ( SELECT id, CASE WHEN addr LIKE '%北京%望京%' THEN 10 WHEN addr LIKE '%北京%' AND addr LIKE '%朝阳%' THEN 8 WHEN addr LIKE '%北京%' THEN 5 ELSE 0 END AS score FROM addresses ) s ON u.id = s.id WHERE s.score > 0 ORDER BY s.score DESC关键点：分数必须是确定性计算（不能依赖外部变量），且子查询需返回
id 和 score 两列；JOIN 比 IN 更利于后续排序和扩展字段。
避免子查询重复扫描和 LIKE 性能陷阱
LIKE '%xxx%' 在大数据量下必然走全表扫描，如果子查询还嵌套多层，性能会断崖式下跌。实际部署前必须检查执行计划：EXPLAIN 看是否用了索引。可行的优化手段包括：
- 对高频模糊字段建全文索引（如 MySQL 的
FULLTEXT，PostgreSQL 的tsvector） - 把模糊逻辑下推到应用层预处理：比如用 ES 或 SQLite FTS 提前生成匹配 ID 列表，再传入 SQL
- 限制子查询返回行数，加
LIMIT防止拖垮主查询（尤其在分页场景） - 避免在子查询里对大文本字段反复
LIKE，可先用CHAR_LENGTH或正则粗筛（如addr REGEXP '北京|朝阳|望京'）再细判
MySQL 8.0+ 用 WITH + ROW_NUMBER 实现带权重的 Top-N 排序
如果目标是“取每个城市下匹配度最高的前 3 条”，用传统子查询嵌套容易混乱。MySQL 8.0 起支持 WITH 公共表表达式，配合窗口函数更清晰：
WITH scored AS ( SELECT a.id, a.addr, u.name, CASE WHEN a.addr LIKE '%北京%' THEN 1 ELSE 0 END + CASE WHEN a.addr LIKE '%地铁%' THEN 2 ELSE 0 END AS weight FROM addresses a JOIN users u ON a.user_id = u.id) SELECT * FROM ( SELECT *, ROW_NUMBER() OVER (PARTITION BY SUBSTRING_INDEX(addr, '市', 1) ORDER BY weight DESC) AS rn FROM scored) t WHERE t.rn <= 3注意：
PARTITION BY 的分组字段必须是确定值（不能是模糊结果），否则窗口函数行为不可控；ROW_NUMBER() 是严格排序编号，若要允许并列用 RANK()。
真正难的不是写出能跑的语句，而是让模糊匹配的“相关性”和数据库的执行路径对齐——比如你给“北京朝阳望京”打了 10 分，但底层没走索引，那这个分再高也没人看得到。
