多条件联合查询关键在逻辑结构匹配业务意图：AND要求所有条件同时为真，OR只需一个为真；混合使用必须加括号；高区分度条件前置；需警惕NULL、引号、索引失效及执行计划问题。

多条件联合查询不是靠堆条件就能准，关键在逻辑结构是否匹配业务意图。AND 和 OR 看似简单，但写错一个括号、漏一个优先级，结果就可能全错。

AND 要求所有条件同时为真，不能当“并且顺便”用

很多人误把 AND 当成自然语言里的“而且”，比如想查“北京的客户，或者上海的 VIP 客户”，却写成：WHERE city = '北京' AND (city = '上海' AND is_vip = 1)——这实际查的是“既是北京又是上海”的记录，永远为空。

• AND 是交集操作：每加一个条件，结果集只会变小或不变
• 数值型字段不用引号，字符串必须用单引号，否则可能隐式转换失败或索引失效
• 如果某个字段允许 NULL，column = 'X' 不会匹配 NULL 行，需要显式写 column IS NULL 或用 COALESCE

OR 只要一个为真就成立，但性能容易被低估

OR 看似宽松，但数据库优化器常难为其生成高效执行计划。例如 WHERE status = 'active' OR created_at > '2025-01-01'，若两个字段无联合索引，很可能触发全表扫描。

• 多个 OR 分支尽量让字段落在同一索引上，否则考虑拆成 UNION ALL
• OR 与 IN 在单字段等值判断时语义接近，但 IN 更易被优化（如 country IN ('CN', 'US', 'JP')）
• 避免 OR 连接带函数的条件，如 UPPER(name) = 'MARY' OR age + 1 > 30，基本无法走索引

混合使用 AND/OR 时，括号不是可选，是必需

SQL 中 AND 优先级恒高于 OR，不加括号等于默认套了 (A AND B) OR C。但人脑读 A AND B OR C 常默认理解为 A AND (B OR C)，这就是 bug 温床。

• 哪怕只有一处混合，也强制加括号，例如：WHERE (type = 'order' AND amount > 100) OR (type = 'refund' AND amount
• 用缩进和换行辅助阅读，但别依赖格式——执行器只认括号
• 测试时务必用边界数据验证，比如插入一条 type='order' 但 amount=50 的记录，看它是否意外被查出

WHERE 条件顺序不影响结果，但可能影响可读性和维护性

数据库引擎会重排执行顺序，WHERE a = 1 AND b > 100 AND c LIKE '%x%' 和把 c LIKE 放最前效果一样。但人读起来差别很大。

• 把高区分度、能快速过滤的条件放前面（如主键等值、有索引的范围），方便后期接手的人一眼抓住筛选主干
• 把易变的业务规则条件（如状态码、时间窗口）和稳定的维度条件（如国家、品类）分组摆放
• 避免一行写太长，每个条件独立成行更利于 Git diff 和注释定位

真正棘手的从来不是语法对不对，而是「这个条件组合到底想表达什么业务含义」——写完多问一句：如果某条数据刚好卡在两个条件的边界上，它该不该出现？答案不确定，括号和测试就得跟上。