any和all是量词而非函数，必须紧贴比较操作符使用（如>any、=all），空子查询时any恒假、all恒真，null值导致unknown而整行被过滤，推荐用exists替代并显式处理空集与null。
ANY和ALL不是函数，不能加括号调用
直接写 ANY() 或 ALL() 会报错——这是最常踩的第一个坑。它们是量词（quantifier），必须紧贴比较操作符使用，例如：> ANY、= ALL、（<code>SOME 是 ANY 的同义词）。
错误写法：WHERE id ANY (SELECT manager_id FROM team)（缺操作符）
正确写法：WHERE id = ANY (SELECT manager_id FROM team WHERE manager_id IS NOT NULL)
空子查询时ALL恒真、ANY恒假，极易引发逻辑漏洞
当子查询返回空集时：
• > ALL (SELECT ...) 自动为 TRUE，整行被保留
• > ANY (SELECT ...) 自动为 FALSE，整行被过滤
这在业务中非常危险。例如：SELECT * FROM staff WHERE salary > ALL (SELECT salary FROM employees WHERE dept = 'HR')，若 HR 部门当前无人，结果会返回所有员工，而非“无匹配”。
- 优先改用
EXISTS显式控制空集行为：AND EXISTS (SELECT 1 FROM employees WHERE dept = 'HR') - 若业务确实需要“空集即成立”，必须加注释说明，否则后续维护者大概率误修
- 测试时务必覆盖空数据场景（如清空测试表后重跑）
NULL值会让ANY/ALL返回UNKNOWN，整行静默丢失
子查询只要含一个 NULL，比如 (101, NULL, 103)，那么 id = ANY(...) 就进入三值逻辑，结果为 UNKNOWN；而 WHERE 只接受 TRUE，UNKNOWN 和 FALSE 都被过滤——看起来“没查到”，实则是逻辑中断。
- 最稳妥做法：子查询显式过滤
WHERE manager_id IS NOT NULL - 更健壮替代：用
EXISTS重写，例如把id = ANY (SELECT manager_id FROM team)改成EXISTS (SELECT 1 FROM team WHERE team.manager_id = staff.id AND team.active = 1) - 别依赖
NOT IN：它遇NULL直接全失效（3 NOT IN (1,2,NULL)永远为FALSE）
性能陷阱：旧版数据库可能重复执行子查询
在 MySQL 5.7 或旧版 PostgreSQL 中，> ANY (SELECT salary FROM sales) 可能被优化器展开为对外层每一行都重跑一次子查询，而不是物化一次复用结果。即使只执行一次，若子查询结果未被索引覆盖，仍需逐行扫描外层表判断。
- 确保子查询中的筛选字段有联合索引，例如
WHERE dept = 'Sales'应配(dept, salary)索引 - 若子查询结果固定且小（如几十个 ID），可提前查出，改写为字面量：
salary IN (5000, 6200, 7800) - PostgreSQL 可用
ANY(ARRAY[])+ 数组索引；MySQL 8.0+ 推荐用 CTE 预计算子查询
复杂点不在语法本身，而在三值逻辑与空集语义的叠加效应——同一句 > ALL 在不同数据状态下可能产生完全相反的业务效果，且无报错提示。
