SQL多条件筛选：避开逻辑运算符的那些“坑”
SQL中AND优先级高于OR，混用时必须加括号明确逻辑；多值匹配应使用IN而非冗长OR；NOT作用范围仅限紧邻表达式，否定多条件需括号包裹；动态条件宜服务端拼接而非SQL内CASE判断。
WHERE里混用AND和OR不加括号，结果完全不对
在SQL的世界里，AND的优先级高于OR，这个规则和多数编程语言一样。但问题在于，写查询时我们很容易凭直觉下笔，结果就掉进了坑里。举个例子：你想找“北京的男用户”或者“上海的女用户”。如果写成 WHERE city = '北京' AND gender = '男' OR city = '上海' AND gender = '女'，逻辑上倒是对的，因为它等价于 (city = '北京' AND gender = '男') OR (city = '上海' AND gender = '女')。但要是手一滑，写成了 WHERE city = '北京' OR city = '上海' AND gender = '女'，那意思可就全变了——数据库会理解成“所有北京用户，再加上上海的女性用户”，这和你想要的“北京女性或上海女性”完全是两码事。
所以，到底该怎么避免这种尴尬？记住下面几条实操建议：
- 只要
WHERE子句里同时出现了AND和OR，别犹豫，立刻用括号把逻辑分组明确下来。哪怕你觉得“这次肯定没错”，也加上括号，这是对自己负责。 - 动笔写SQL之前，不妨先在纸上把逻辑关系画清楚，比如明确写出(A AND B) OR (C AND D)的结构，然后再原封不动地翻译成SQL代码。边想边敲，最容易出错。
- 这个优先级规则是SQL标准，无论是MySQL、PostgreSQL还是SQL Server，全都一视同仁。别指望换个数据库环境，它就能“智能”地理解你的本意。
IN配合OR写一堆=条件，又慢又难维护
遇到需要匹配多个值的情况，比如想查询北上广深四个城市的用户，有些朋友会不假思索地写下一长串：WHERE city = '北京' OR city = '上海' OR city = '广州' OR city = '深圳'。这么写，问题可不止一个：代码冗长难读；当字段没有索引时，执行计划可能效率低下；更别提万一漏写一个OR，直接就是语法错误。
其实，一个更优雅、更专业的解决方案就摆在那里：
- 直接用
IN操作符来替代那一长串OR。上面的例子可以简洁地写成：WHERE city IN ('北京', '上海', '广州', '深圳')。清晰，直白，易于维护。 - 不过，使用
IN也得注意尺度。列表里的值最好不要超过几百个，像SQLite这类数据库有编译限制，MySQL也受max_allowed_packet配置影响，数据量太大可能被截断。如果值真的非常多，考虑拆分成多个查询，或者使用临时表来关联。 - 这里有个关键细节：
NULL值在IN列表里是永远无法匹配的。也就是说，WHERE status IN ('active', NULL)这个条件，其中的NULL部分是完全无效的。如果想包含NULL，必须单独加上OR status IS NULL。
NOT与AND/OR连用时语义容易翻车
NOT这个操作符，作用范围有点“近视”——它只否定紧挨着它的那个表达式，而不是整个WHERE子句。举个例子：WHERE NOT status = 'deleted' AND created_at > '2023-01-01'，数据库会理解为 (NOT status = 'deleted') AND created_at > '2023-01-01'，这没问题。但如果你想表达“状态既不是‘deleted’也不是‘archived’”，就必须写成 WHERE NOT (status = 'deleted' OR status = 'archived')。看见了吗？少了一对括号，整个逻辑意思就可能完全相反。
因此，处理否定逻辑时，务必格外小心：
- 当需要否定一组条件时，最稳妥的办法是先用括号把这组条件包成一个整体，然后在前面加上
NOT。 - 在简单的情况下，能用
!=或<>直接替代NOT =的，就别绕弯子，这样代码更直观。（当然，比较NULL时还是得用IS NOT NULL。） - 另外，像PostgreSQL支持
NOT IN，但这里有个经典的陷阱：如果IN的列表里包含NULL值，那么整个NOT IN条件的结果会是空（NULL），而不是你期望的“不在列表中”。这是逻辑设计使然，并非系统漏洞。
参数化查询里传入动态条件，拼SQL还是用CASE？
在后端开发中，我们经常需要根据前端传入的参数动态构建查询条件。比如，搜索功能中“城市”这个参数可能为空。如果直接在SQL里拼接AND city = ?，当参数为空时就会导致语法错误。于是，有人想出了一个“聪明”的办法：在WHERE子句里使用CASE WHEN来判断参数是否为空。但这样一来，往往会让查询优化器变得困惑，导致无法使用索引，性能急剧下降。
那么，正确的做法是什么？
- 把逻辑判断放在服务端代码里。在拼接SQL字符串时，就通过程序逻辑判断参数是否有效，从而决定是否追加
AND city = ?这样的子句。让SQL语句本身保持干净、直接。 - 尽量避免在WHERE条件中使用
CASE表达式来做“条件开关”。像AND (CASE WHEN ? IS NOT NULL THEN city = ? ELSE 1=1 END)这种写法，虽然功能上可能实现，但大概率会让数据库优化器放弃使用索引，因小失大。 - 主流的数据访问框架，比如MyBatis的
Q对象，其底层原理也正是如此：在代码层面动态生成结构清晰、无冗余条件的SQL语句，而不是把一堆判断逻辑塞进数据库去执行。
说到底，SQL中的括号不仅仅是语法符号，更是明确逻辑关系的锚点；而参数化查询也不仅仅是为了防止SQL注入，它更是构建动态、高效查询的起点。写完一个复杂的WHERE子句后，不妨先做两件事：检查一下括号是否都成对匹配了，再想想NULL值的情况是否处理妥当。这两步如果偷了懒，后面再怎么调整执行计划，恐怕都难以挽回性能的损失。
