用ANY替代MAX()子查询结果常为空，因>ANY表示“比任意一个值大”（即大于最小值），而非大于最大值；真正等价于MAX()的是>ALL，但需防范空子查询和NULL导致的逻辑异常与性能退化。
用 ANY 替代 MAX() 子查询时，为什么结果常为空？
直接写 WHERE salary > ANY (SELECT salary FROM emp) 并不等价于“找最高工资以上的人”——它实际查的是“比任意一个工资高的人”，只要比最低工资高就满足，结果往往远多于预期。
真正想表达“高于所有人”，必须搭配 > 和 ALL：WHERE salary > ALL (SELECT salary FROM emp) 才等价于 salary > (SELECT MAX(salary) FROM emp)。
反过来， 等价于 <code>，<code>> ALL 等价于 > MAX()， 等价于 <code>。
ALL 在空子查询时返回 TRUE，这会引发意外匹配
当子查询没返回任何行（比如 SELECT salary FROM emp WHERE dept = 'ZZZ'），salary > ALL (…) 逻辑上为真——因为“大于所有（零个）值”在 SQL 中被定义为真。这会导致本该无结果的查询返回全表数据。
必须显式防御：
- 加
WHERE EXISTS (SELECT 1 FROM emp WHERE dept = 'ZZZ')前置判断 - 或改用聚合：把
> ALL (SELECT salary FROM emp WHERE dept = 'ZZZ')换成> COALESCE((SELECT MAX(salary) FROM emp WHERE dept = 'ZZZ'), -999999)
PostgreSQL / MySQL / SQL Server 对 ANY/ALL 的 NULL 处理不一致
若子查询含 NULL，> ALL 行为分化明显：
— PostgreSQL：只要子查询有 NULL，> ALL 整体返回 UNKNOWN（即该行不匹配）
— MySQL 8.0+：同样返回 UNKNOWN
— SQL Server：直接报错 “Subquery returned more than 1 value”（如果未用聚合包裹）
安全做法是提前过滤：WHERE salary IS NOT NULL AND salary > ALL (SELECT salary FROM emp WHERE salary IS NOT NULL)
性能上，ANY/ALL 子查询通常不如聚合函数友好
优化器对 ALL 的执行计划常退化为嵌套循环或临时排序，尤其子查询结果大时；而 MAX()/MIN() 可利用索引快速定位极值。
实测中，以下写法更稳：
SELECT * FROM emp WHERE salary = (SELECT MAX(salary) FROM emp);
而不是：
SELECT * FROM emp WHERE salary >= ALL (SELECT salary FROM emp);
后者在百万级表上可能慢 3–5 倍，且难以加有效索引提示。
用 ANY/ALL 改写极值查询，本质是换了一种逻辑表达，但不是语法糖——它改变了空值、NULL、执行路径三处关键行为，线上环境务必验证子查询非空和 NULL 分布。
