最常见的问题是结果错误而非性能差，因and优先级高于or，未加括号时where a=1 or b=2 and c=3等价于a=1 or (b=2 and c=3)；应显式加括号或用in替代多or，避免函数作用于索引字段。
WHERE 中 AND 和 OR 混用导致逻辑错乱
最常见的问题不是性能差，而是结果不对——AND 优先级高于 OR，没加括号时，WHERE a = 1 OR b = 2 AND c = 3 实际等价于 WHERE a = 1 OR (b = 2 AND c = 3)，而不是你直觉想表达的 (a = 1 OR b = 2) AND c = 3。
实操建议：
- 所有含
OR的组合，只要不是最外层单条件，一律用括号显式包裹，比如WHERE (status = 'active' OR status = 'pending') AND created_at > '2024-01-01' - 用
IN替代多个OR等值判断，语义清晰且多数引擎能更好优化：WHERE status IN ('active', 'pending') - 避免在
OR左右两侧混用不同字段的范围查询（如date > '2024' OR amount > 1000），这类组合几乎无法走索引，后续会单独讲
带函数或计算的 WHERE 条件让索引失效
写 WHERE UPPER(name) = 'JOHN' 或 WHERE DATE(created_at) = '2024-01-01'，哪怕 name 或 created_at 有索引，也基本白搭。数据库没法用索引去匹配“先算一遍再比”的值。
实操建议：
- 把函数移到右侧：用
WHERE name = UPPER('john')（注意大小写一致性）或WHERE created_at >= '2024-01-01' AND created_at - 对固定模式做函数索引（PostgreSQL/MySQL 8.0+ 支持）：
CREATE INDEX idx_upper_name ON users (UPPER(name))，但只在明确总是按该方式查询时才建 - 时间字段慎用
YEAR()、HOUR()等提取函数，它们强制全表扫描；改用范围比较更可靠
NULL 值参与比较引发意外空结果
WHERE column = NULL 永远不返回任何行，因为 SQL 中 NULL = NULL 是未知（UNKNOWN），不是真；同理 != NULL、> NULL 全部无效。
实操建议：
- 判空必须用
IS NULL或IS NOT NULL，这是唯一标准写法 - 需要把
NULL当作某个具体值参与逻辑时，用COALESCE(column, 'default')或NULLIF()显式转换，但注意这又可能让索引失效 - 联表查询中，
ON条件若含可能为NULL的字段（比如LEFT JOIN右表字段），别直接在WHERE里写right_table.id != 5，它会把NULL行过滤掉；应写成right_table.id IS NULL OR right_table.id != 5
IN 列表过长拖慢执行甚至超限
MySQL 默认 max_allowed_packet 限制单条语句长度，PostgreSQL 对 IN 元素数量无硬限制但解析/计划耗时明显上升。传 5000 个 ID 进 IN，可能卡在语法分析阶段，或者生成极低效的执行计划。
实操建议：
- 超过几百个值就别硬塞
IN，改用临时表 +JOIN：先CREATE TEMP TABLE tmp_ids (id INT)，批量插入，再SELECT * FROM orders JOIN tmp_ids ON orders.user_id = tmp_ids.id - 如果只是前端分页查“某批 ID”，考虑用
VALUES表达式（PostgreSQL）或UNION ALL构造集（兼容性更好） - MySQL 用户注意：
IN列表中含子查询（如IN (SELECT id FROM ...)）时，5.7+ 会尝试物化，但复杂嵌套仍易退化；优先拆成两步
真正难的不是写对 WHERE，而是想清楚数据分布和索引覆盖是否匹配你的条件顺序——比如 WHERE deleted = 0 AND tenant_id = 123 AND status = 'done'，如果 deleted 列只有两个值，放最前反而可能阻碍索引选择，这时候就得看实际 EXPLAIN 结果，而不是背口诀。
