where子句是sql执行过滤的强制入口，必须位于from之后、group by之前；它在聚合前逐行处理，故不可用count(*)等聚合函数，字符串需注意空格与引号，日期格式依数据库方言而异，多条件须用括号明确逻辑优先级。
WHERE 子句不是“可选优化项”，而是 SQL 执行过滤的强制入口——没它，SELECT 就扫全表；写错位置或类型，结果就错得无声无息。
WHERE 必须写在 FROM 之后、GROUP BY 之前
这是执行顺序决定的硬约束：WHERE 在聚合前逐行判断，所以它看不到 COUNT(*)、SUM(price) 这类聚合结果。
常见错误现象：Invalid use of an aggregate function（Access）或直接报语法错（PostgreSQL/SQL Server）。
- 错误写法：
SELECT category, COUNT(*) FROM products WHERE COUNT(*) > 5 GROUP BY category - 正确拆分：
SELECT category, COUNT(*) FROM products WHERE discontinued = false GROUP BY category HAVING COUNT(*) > 5 -
WHERE管原始行（比如只查未下架产品），HAVING管分组后（比如每类至少有 5 个）
字符串、日期、NULL 的写法差异极大
不同数据库对字面量格式敏感度天差地别，同一写法在 Access 里能跑，在 PostgreSQL 里直接报错。
字符串比较要防空格和大小写：
- Access 默认不区分大小写，但
[LastName] = 'Bagel '（末尾空格）永远不等于实际存的'Bagel' - 安全写法：
WHERE Trim([LastName]) = 'Bagel' - 模糊匹配注意通配符：
LIKE 'Micro%'（标准 SQL），但 Access 用LIKE 'Micro*'
日期必须按方言来：
- Access：必须用
#4/15/26#或DateValue('15-Apr-2026')，写'2026-04-15'会静默失败 - PostgreSQL：
WHERE order_date = '2026-04-15'::DATE或直接'2026-04-15'（支持 ISO 格式） - NULL 判断只能用
IS NULL，不能写= NULL——后者永远返回 FALSE
多条件组合时 AND/OR 优先级容易翻车
SQL 按照 NOT → AND → OR 顺序计算，不加括号极易误判逻辑。
比如想查“类别是 1 或 8，且价格大于 50”的产品：
- 危险写法：
WHERE category_id = 1 OR category_id = 8 AND price > 50→ 实际等价于category_id = 1 OR (category_id = 8 AND price > 50) - 明确写法：
WHERE (category_id = 1 OR category_id = 8) AND price > 50 - 更简洁写法：
WHERE category_id IN (1, 8) AND price > 50（语义清晰，也利于索引使用）
IN 和 OR 表面等价，但某些旧版 Access 对 IN 的索引支持更稳；而 NOT IN (1, 2) 遇到字段含 NULL 时可能整条记录被跳过——这点常被忽略。
JOIN 场景下 WHERE 不该承担关联职责
把联接逻辑塞进 WHERE（比如 SELECT * FROM a, b WHERE a.id = b.a_id），本质是隐式笛卡尔积，漏条件就爆炸。
真实项目中一旦表变大，这种写法性能断崖下跌，且难以维护。
- 显式写法更安全：
SELECT * FROM orders INNER JOIN customers ON orders.customer_id = customers.id - 如果真要用
WHERE做联接，请确保等值条件一个不落，且所有 JOIN 字段都有索引 - LEFT JOIN 后的过滤条件要注意：写在
ON还是WHERE，决定的是“保留左表全部”还是“只留匹配后满足条件的”——这个区别线上出过太多数据丢失事故
WHERE 看似简单，但它在执行链最前端卡住每一行，任何类型隐式转换、函数包裹、空值陷阱，都会在这里放大成查询结果偏差或性能雪崩。真正难的不是写出来，而是写对——尤其当多个数据库方言混用时，同一个 WHERE 条件可能在三套环境里有三种行为。
