WHERE是Access SQL中筛选数据的强制开关，执行于聚合前、逐行处理，须用#包裹日期、慎用函数，多表查询应优先用显式JOIN。
直接说结论：WHERE 子句是 Access SQL 中筛选数据的唯一标准入口，不是“可选技巧”，而是执行 SELECT、UPDATE、DELETE 时控制作用范围的强制开关——漏写或写错，结果要么全表扫，要么查不到想要的记录。
WHERE 后面不能直接跟聚合字段（比如 COUNT、SUM）
这是新手最常踩的坑。Access 会直接报错：Invalid use of an aggregate function。因为 WHERE 在聚合计算前就执行，它看不到聚合后的值。
- 错误写法：
SELECT Category, COUNT(*) FROM Products GROUP BY Category WHERE COUNT(*) > 5 - 正确做法：把条件挪到
HAVING子句，WHERE只管原始行级过滤，例如：SELECT Category, COUNT(*) FROM Products WHERE Discontinued = False GROUP BY Category HAVING COUNT(*) > 5 - 注意：
HAVING必须跟在GROUP BY后面，且不能脱离分组存在
日期条件必须用 # 包裹，或用 DateValue() 转换
Access 对日期字面量格式极其敏感。直接写 '2026-04-15' 或 '15/04/2026' 会静默失败或匹配错乱——它只认美国式短格式 + 数字符号包裹。
- 安全写法：
WHERE OrderDate = #4/15/26#（注意不是#2026/04/15#，年份缩写两位更稳） - 国际兼容写法：
WHERE OrderDate = DateValue('15-Apr-2026')，DateValue()会按系统区域设置解析 - 别用
Format()函数在 WHERE 里做转换，它返回文本，会导致索引失效和类型隐式转换
文本字段比较要小心空格和大小写
Access 默认不区分大小写，但会严格比对前后空格。比如 [LastName] = 'Bagel '（末尾有空格）永远不等于实际存储为 'Bagel' 的记录。
- 查前缀用
LIKE：WHERE [CompanyName] LIKE 'Micro%' - 去空格再比：
WHERE Trim([ContactName]) = 'John Smith' - 模糊查含某词：
WHERE [Notes] LIKE '*shipping*'（Access 用星号 * 代替百分号 %） - 避免在 WHERE 里用
IIf()或嵌套函数做逻辑判断，性能差且难调试
多表查询没写 JOIN 时，WHERE 承担联接职责但极易出错
如果写 SELECT * FROM Orders, Customers WHERE Orders.CustomerID = Customers.ID，这本质是旧式隐式联接。一旦漏掉等值条件，就会触发笛卡尔积——1000 行 × 1000 行 = 百万级无意义结果。
- 强烈建议显式写
INNER JOIN：SELECT * FROM Orders INNER JOIN Customers ON Orders.CustomerID = Customers.ID - 若真要用 WHERE 联接，必须确保每个表至少有一个等值关联条件，且所有关联字段类型一致（数字对数字，文本对文本）
- 跨类型匹配（如文本 ID 字段 vs 数字 ID 字段）不能靠 WHERE 硬转，得先用
CInt()或CStr()显式转换，否则可能部分匹配失败
真正麻烦的从来不是语法本身，而是 WHERE 执行时机——它发生在数据读取阶段，任何函数调用、类型转换、字符串操作都会逐行执行。所以看似简单的条件，一旦嵌套三层函数，查询速度就断崖下跌。先想清楚要不要筛，再决定怎么筛。
