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
• 混合搜索字段：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)有助于人眼快速识别瓶颈

括号本身不消耗性能，但错误的分组会让优化器选错执行策略，这种问题在线上查慢查询时最难定位。