AND优先级高于OR，不加括号时SQL先执行AND再执行OR，如WHERE A OR B AND C等价于WHERE A OR (B AND C)，该规则在MySQL、PostgreSQL等所有主流数据库中一致。
AND和OR的默认执行顺序是什么
SQL中AND的优先级高于OR，这意味着不加括号时，AND条件会先被组合计算。比如WHERE status = 'active' OR type = 'admin' AND level > 5实际等价于WHERE status = 'active' OR (type = 'admin' AND level > 5)，而不是按书写顺序从左到右。
- 这个规则在所有主流数据库（MySQL、PostgreSQL、SQL Server、SQLite）中一致
- 不依赖括号时容易误判逻辑，尤其在多条件混用场景下
-
NOT优先级最高，但日常查询中AND/OR组合更常引发歧义
什么时候必须用括号明确分组
只要逻辑不是“全部AND”或“全部OR”，就该用括号——哪怕只是直觉上“应该没问题”。典型易错场景包括：
- 查询“VIP用户或普通用户中的高活跃者”：
WHERE role = 'vip' OR (role = 'user' AND login_count > 100) - 排除多个条件组合：
WHERE NOT (status = 'deleted' OR (type = 'temp' AND created_at < '2023-01-01')) - 混合搜索字段：
WHERE (name LIKE '%john%' OR email LIKE '%john%') AND is_verified = 1
不加括号时，数据库按固定优先级解析，不会猜测你的业务意图。
用EXPLAIN验证括号是否生效
光看SQL文本无法确认执行逻辑是否如预期，尤其在复杂WHERE中。用EXPLAIN（或EXPLAIN ANALYZE）观察实际过滤步骤：
- PostgreSQL中运行
EXPLAIN SELECT * FROM users WHERE a=1 OR b=2 AND c=3，Filter行会显示((b = 2) AND (c = 3)) OR (a = 1) - MySQL的
EXPLAIN输出中，Extra列若出现Using where，需结合possible_keys和key判断索引是否按你设想的分组使用 - 如果括号改变了执行计划（比如触发了不同索引），说明它确实影响了查询行为，不只是语义装饰
AND/OR混用时性能容易被忽略的点
逻辑分组不仅影响结果正确性，还直接影响优化器选择索引和执行路径：
- 多个
OR分支可能让索引失效，尤其当各分支字段无联合索引时 -
AND连接的条件更容易命中复合索引，但前提是顺序匹配索引定义 - 把高筛选率条件（如
status = 'archived'）放在AND左侧，不一定提升性能——优化器会重排，但写成(high_selectivity) AND (low_selectivity)有助于人眼快速识别瓶颈
括号本身不消耗性能，但错误的分组会让优化器选错执行策略，这种问题在线上查慢查询时最难定位。
