ANY和ALL是量化谓词，必须配合比较运算符与单列子查询使用，不可接值列表或多列；ANY表示“存在一个满足即真”（逻辑OR），ALL表示“全部满足才真”（逻辑AND）；空子查询时ANY恒假、ALL恒真，且均受NULL影响。
ANY 和 ALL 的本质是子查询比较，不是普通函数
它们必须搭配子查询使用，不能直接写 WHERE age > ANY(1, 2, 3)——这会报错。SQL 把 ANY 和 ALL 当作量化谓词，左边是标量表达式，右边必须是单列子查询。
常见错误现象：ERROR: syntax error at or near "1" 或 subquery must return only one column，基本都是因为子查询返回了多列或多行结构不匹配。
-
ANY等价于 “只要有一个满足就为真”，类似逻辑 OR 展开：val > ANY(SELECT x FROM t)⇔val > x1 OR val > x2 OR ... -
ALL等价于 “全部都满足才为真”，类似逻辑 AND 展开：val > ALL(SELECT x FROM t)⇔val > x1 AND val > x2 AND ... - 子查询为空时，
ANY返回 FALSE（没一个可比，自然不成立），ALL返回 TRUE（没有反例，视为全满足）——这点极易被忽略
用 > ANY 替代 IN 实现“大于任一值”的语义
IN 只能做相等判断，而 > ANY 是唯一简洁表达“比最小值还大”的方式。例如找薪资高于任意部门平均薪资的员工：
SELECT name, salary FROM employees WHERE salary > ANY (SELECT AVG(salary) FROM employees GROUP BY dept_id);
注意：这里子查询返回的是多个平均值（每部门一个），> ANY 表示“高于其中任意一个”，即“高于最低的那个平均值”。如果误写成 > ALL，就变成“高于所有部门平均值”，语义完全不同。
- 性能上，多数数据库会对
ANY/ALL子查询做优化，但若子查询无索引或结果集大，可能触发嵌套循环；建议在子查询的GROUP BY字段或聚合键上建索引 - MySQL 5.7+ 支持该语法，但旧版本需改写为
JOIN+ 窗口函数或临时表 - PostgreSQL 和 SQL Server 对空子查询的处理一致；Oracle 则要求子查询非空，否则报
ORA-01428: argument 'null' is out of range
ALL 常用于“全局最值”类过滤，但要防 NULL 干扰
比如查出“工资不低于公司每个员工”的人（即最高薪者）：salary >= ALL(SELECT salary FROM employees)。看似简单，但一旦 salary 列含 NULL，整个表达式结果为 UNKNOWN（三值逻辑），导致该行被过滤掉。
- 安全写法是显式排除 NULL：
salary IS NOT NULL AND salary >= ALL(SELECT salary FROM employees WHERE salary IS NOT NULL) -
= ALL极少有用——它要求目标值等于子查询返回的每一个值，只有子查询只返回一个非 NULL 值时才可能为真 - 用
找严格小于所有值的记录时，等价于 <code>；同理 <code>> ALL≡> MAX()，但语义更明确、可读性更好
替代方案：窗口函数通常更高效且可控
当需要多次复用子查询结果（如同时对比部门均值和公司均值），硬套 ANY/ALL 会导致子查询重复执行。此时用窗口函数更稳：
SELECT name, salary,
AVG(salary) OVER(PARTITION BY dept_id) AS dept_avg,
AVG(salary) OVER() AS company_avg
FROM employees
WHERE salary > dept_avg OR salary > company_avg;
这种写法避免了子查询，也绕开了空结果、NULL、重复计算等问题。
- 某些场景下
ANY/ALL无法替代：比如子查询涉及复杂 JOIN 或参数化条件，窗口函数难以覆盖 - SQLite 直到 3.25.0 才支持窗口函数，老版本仍需依赖
ANY/ALL - 真正容易被忽略的是子查询的执行时机：它在每行外层 WHERE 求值时都会运行一次，不是预计算——这意味着带
LIMIT或ORDER BY的子查询行为可能不符合直觉
