多条件联合查询关键在逻辑结构匹配业务意图：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 和注释定位
真正棘手的从来不是语法对不对，而是「这个条件组合到底想表达什么业务含义」——写完多问一句：如果某条数据刚好卡在两个条件的边界上，它该不该出现？答案不确定，括号和测试就得跟上。
