直接用in列出多字段组合是最简方案，但易因null或类型不匹配静默失败；“同时满足多个条件”需区分场景：若指一行中多个字段各自满足条件，用and连接；若指多组字段值任一匹配，则用(a,b) in ((1,'x'),(2,'y'))，要求字段数、顺序、类型严格一致。
直接用 IN 列出多字段组合是最简方案，但容易因 NULL 或类型不匹配静默失败；真要“同时满足多个条件”，得看你是想查「一行里多个字段各自满足各自条件」，还是「多组字段值的任意组合匹配」——二者写法完全不同，别混用。
WHERE 中多个字段各自带条件：用 AND 连接
这是最常见场景：比如查「年龄 ≥ 18 且城市是北京且状态为激活」的用户。每个条件作用于不同字段，逻辑上必须同时成立。
-
AND是唯一正确选择，OR会扩大结果集，IN在这里语法错误（WHERE age IN (18, 19) AND city IN ('北京', '上海')是合法的，但和“同时满足”不是同一问题） - 注意 NULL：如果某字段允许 NULL，
city = '北京'不会命中 NULL 行，但也不会报错；若需包含 NULL，得显式写city = '北京' OR city IS NULL - 字符串比较注意大小写和空格：MySQL 默认不区分大小写，PostgreSQL 区分；建议统一用
TRIM(UPPER(city)) = 'BEIJING'避免隐式差异
(a,b) IN ((1,'x'),(2,'y'))：匹配字段组合对
当你要找的是「(user_id, status) 这一对值恰好等于 (101, 'active') 或 (205, 'pending')」这类组合时，括号元组 + IN 是标准写法。
- 必须确保左右两边字段数、顺序、数据类型严格一致：比如左边是
(int, varchar)，右边就不能写(101, 1)或('101', 'active')，否则 MySQL 可能隐式转换导致索引失效，SQL Server 直接报错 - 子查询里不能返回 NULL：
SELECT * FROM users WHERE (id, status) IN (SELECT id, status FROM logs)—— 如果logs.id有 NULL，整行匹配失败，结果为空（即使其他行都匹配） - 替代方案：用
EXISTS+ 关联，更安全：EXISTS (SELECT 1 FROM logs l WHERE l.id = users.id AND l.status = users.status)
子查询返回单列但需多条件过滤：优先用 EXISTS
例如查「在订单表中有总金额 > 1000 且创建时间在最近 30 天内的用户」，子查询本身要同时满足两个条件，但外层只靠一个字段关联。
- 别写
WHERE user_id IN (SELECT user_id FROM orders WHERE amount > 1000 AND created_at > NOW() - INTERVAL 30 DAY)—— 看似没问题，但如果orders.user_id允许 NULL，哪怕只有一行是 NULL，整个IN就返回空集 - 改用
EXISTS：它不依赖子查询结果是否含 NULL，只关心是否存在匹配行，语义更清晰，优化器也更容易下推条件 - 子查询里
SELECT 1比SELECT *更好，明确意图，避免传输无关字段
涉及角色继承或多层权限时：WITH RECURSIVE 不能省
如果条件是「用户拥有角色 A，而 A 继承自 B，B 又继承自 C，且 C 有 edit_article 权限」，硬写多层 IN 或 OR 会漏数据，且无法表达递归关系。
- 必须用递归 CTE 展开所有继承路径，再拿结果去 join 权限表；PostgreSQL/SQL Server 支持，MySQL 8.0+ 也支持，但老版本只能靠应用层拼接
- 递归部分必须有终止条件（如
MAXRECURSION或SEARCH DEPTH FIRST），否则可能死循环 - 展开后的结果集常有重复，记得加
DISTINCT或在外层GROUP BY
真正麻烦的不是语法，而是条件之间的逻辑关系——是“同一行内多个字段各自达标”，还是“多组键值对中任一匹配”，或是“跨表多层依赖”。写之前先画个真值表，比急着敲 IN 安全得多。
