WHERE多条件必须用AND连接，字符串加单引号，NULL需用IS NULL判断，AND顺序不影响性能但索引列顺序关键，混用AND/OR必须加括号防歧义。
直接用 AND 连接多个条件就行，不需要函数、不需嵌套、也不用逗号分隔——写错就报语法错误。
WHERE 后面多个条件必须用 AND（不能用逗号）
常见错误是把 WHERE age > 18, city = 'Beijing' 当成合法写法，这会立刻触发 ERROR: syntax error at or near ","。MySQL 只认逻辑运算符：AND、OR、NOT。
- 正确写法：
WHERE age > 18 AND city = 'Beijing' - 字符串值必须加单引号，数字不用：
status = 'active'✅，id = 123✅，但id = '123'可能触发隐式转换，索引还可能失效 - 字段名含空格或关键字时要转义：PostgreSQL 用双引号，如
"user name"；MySQL 用反引号，如`order`
NULL 值会让 AND 条件静默失败
AND 遇到 NULL 时整个表达式结果是 UNKNOWN，而 WHERE 只接受 TRUE，所以含 NULL 的行直接被过滤掉——哪怕其他条件都成立。
- 例如：
WHERE age > 18 AND city = 'Beijing'，若某行city是NULL，该行不会出现，哪怕age > 18为真 -
= NULL永远返回FALSE，查不到任何东西；必须写成city IS NULL或city IS NOT NULL - 想“允许 NULL 且满足其他条件”，得显式写出：
WHERE (city = 'Beijing' OR city IS NULL) AND age > 18，但得确认业务是否真要包含 NULL
AND 条件顺序不影响执行，但索引设计很关键
优化器通常会自动重排 AND 条件顺序，所以 WHERE type = 'user' AND status = 'active' 和反过来写，性能一般没差别。真正卡住的是索引列顺序和查询条件是否匹配。
- 复合索引
INDEX idx_type_status (type, status)能加速WHERE type = 'user' AND status = 'active'，但对WHERE status = 'active'单独查几乎无效 - 高选择性字段（如唯一值多的
user_id）建议放索引前面；范围条件（如created_at > '2024-01-01'）放后面 - 避免在条件里对字段做计算：
WHERE UPPER(name) = 'JOHN'会让索引完全失效 - 用
EXPLAIN看key列是否命中预期索引，别靠猜
AND 和 OR 混用必须加括号
虽然 AND 优先级高于 OR，但人脑容易按从左到右理解，不加括号极易查错数据。
- 错误写法：
WHERE city = 'Beijing' AND role = 'user' OR city = 'Shanghai' AND role = 'admin'，实际等价于(city = 'Beijing' AND role = 'user') OR (city = 'Shanghai' AND role = 'admin')—— 表面看没问题，但漏掉括号后语义模糊，维护时容易改错 - 想表达“北京或上海的用户”，必须写成：
WHERE (city = 'Beijing' OR city = 'Shanghai') AND role = 'user' - 括号不增加运行开销，但能彻底消除歧义，线上环境强烈建议无例外地使用
最常被忽略的其实是 NULL 处理和括号——它们不会报错，但会让查询结果悄悄偏离预期，尤其在数据量变大、字段开始出现空值之后才暴露问题。
