or语句未返回预期结果的主因是null值导致条件判为unknown，且and优先级高于or需加括号，应优先用in替代多个or、显式处理null、参数化防注入、避免索引失效。
OR 语句为什么没返回预期结果
常见原因是字段为 NULL 时，OR 条件整体被判定为 UNKNOWN，不满足 WHERE 筛选逻辑。比如 status = 'active' OR status = 'pending' 会漏掉 status IS NULL 的行，但更隐蔽的问题是：如果某个条件本身含 NULL 比较（如 name = NULL），整个表达式直接失效。
实际使用中优先检查字段是否允许 NULL，并确认业务上是否需要包含空值：
- 用
IS NULL或IS NOT NULL显式处理空值，不要写= NULL - 多个 OR 条件混用时，括号不是可选的——
type = 'A' OR type = 'B' AND status = 'done'实际等价于type = 'A' OR (type = 'B' AND status = 'done')，容易误判 - 若条件来自用户输入，空字符串或空参数可能意外变成
OR name = ''，需提前过滤或用COALESCE(name, '')统一处理
用 IN 替代多个 OR 更安全
当匹配固定枚举值时，IN 不仅语法简洁，还能避免手误漏括号、且多数数据库对 IN 有更好优化。它天然跳过 NULL 元素（IN 列表里写 NULL 会被忽略），行为更可预测。
例如想查状态为 “draft”、“review” 或 “published” 的记录：
SELECT * FROM posts WHERE status IN ('draft', 'review', 'published');
注意三点：
-
IN列表最多支持多少项取决于数据库（PostgreSQL 默认无硬限制，MySQL 受max_allowed_packet影响），超长列表建议分批或改用临时表 -
NOT IN遇到列表含NULL时整条语句返回空结果——这是陷阱，应改用NOT EXISTS或先排除NULL - 如果值来自子查询，确保子查询不返回
NULL，否则IN行为异常
动态拼接 OR 条件时怎么防 SQL 注入
后端拼字符串生成 OR 查询（如根据勾选的标签筛选）时，直接插变量等于敞开大门。必须用参数化查询，哪怕只是多个 OR 分支。
以 Python + psycopg2 为例，不能这样写：
# ❌ 危险拼接<br>query = "SELECT * FROM items WHERE tag = '" + user_input + "' OR category = '" + user_input + "'"
而应构造参数占位符：
# ✅ 动态生成占位符<br>tags = ['web', 'api', 'db']<br>placeholders = ', '.join(['%s'] * len(tags))<br>query = f"SELECT * FROM items WHERE tag IN ({placeholders})"<br>cursor.execute(query, tags)
关键点：
- 每个值单独占位，不拼字符串
- 字段名（如
tag、category）不能参数化，需白名单校验 - 若要 OR 多个字段（如
tag = ? OR category = ? OR author = ?），就准备对应数量的参数，别复用同一个值
OR 导致索引失效的典型场景
单字段索引在 OR 查询中大概率失效，尤其当 OR 两侧字段不同（如 WHERE a = 1 OR b = 2）。数据库优化器通常放弃走索引，改用全表扫描。
可行解法有限，按优先级排列：
- 改用
UNION拆成多个独立查询：(SELECT * FROM t WHERE a = 1) UNION ALL (SELECT * FROM t WHERE b = 2 AND a != 1)，每部分可走各自索引 - 建立组合索引覆盖所有 OR 字段（如
(a, b)），但只对最左前缀有效，b = 2单独查仍用不上 - 用物化视图或冗余字段（如新增
search_key合并常用查询字段），适合读多写少场景
真正难的是 OR 跨类型字段（比如数值 ID 和字符串 name），这时候基本只能接受性能折损，或者推动业务层做缓存预计算。
