all运算符本质是全量比较，要求左侧表达式与子查询每一行均满足比较条件；空结果集时恒为true，含null时结果为unknown，与max()行为迥异。
ALL 运算符本质是「全量比较」，不是「取最大值后比较」
很多人误以为 WHERE x > ALL (subquery) 等价于 WHERE x > (SELECT MAX(y) FROM ...)，但二者在空结果集和 NULL 处理上行为完全不同。当子查询返回空行时，ALL 的结果是 TRUE（因为“没有反例”），而 MAX() 返回 NULL，导致整个比较变成 UNKNOWN，该行被过滤掉——这是最常踩的坑。
- 子查询返回 0 行 →
x > ALL (empty)恒为 TRUE - 子查询含
NULL→ 只要有一个NULL，x > ALL (...)必为 UNKNOWN（即该行不匹配） -
ALL要求左侧表达式与子查询每一行都满足关系，任一不满足即整体为 FALSE
正确写法：用 ALL 实现「严格大于所有值」
典型场景是查出比某个部门所有人薪资都高的员工。注意必须确保子查询只返回单列数值，且避免隐式类型转换引发错误。
SELECT name, salary FROM employees e1 WHERE salary > ALL ( SELECT salary FROM employees e2 WHERE e2.dept = 'Sales' );
- 子查询必须返回**标量列**（如
salary），不能是多列或带表达式的复合结果 - 若子查询中
salary允许为NULL，整条ALL条件会失效；应显式排除：WHERE e2.dept = 'Sales' AND e2.salary IS NOT NULL - MySQL 5.7+ 和 PostgreSQL 支持此语法；SQLite 支持但要求子查询非空（否则报错），SQL Server 不支持
ALL与标量子查询混用（需改用NOT EXISTS）
替代方案对比：为什么有时该避开 ALL
当业务逻辑实际只需要「大于最大值」，且能接受空子查询时返回空结果（而非全部命中），用聚合函数更直观、可控。
-
> ALL在子查询含NULL时静默失败（无报错，但结果为空），排查困难 -
> (SELECT MAX(x) FROM ...)对空结果返回NULL，整行被过滤，行为可预测 - 性能上，优化器对
MAX()通常能利用索引；而ALL在某些引擎中可能触发嵌套循环比较（尤其子查询未优化时） - PostgreSQL 中可用
NOT EXISTS (SELECT 1 FROM ... WHERE salary >= e1.salary)完全等价且 NULL 安全
容易忽略的边界：空子查询和全 NULL 子查询
这两个场景下 ALL 表现反直觉，但恰恰是线上问题高发点。
- 子查询无结果：
SELECT 100 > ALL (SELECT id FROM users WHERE 1=0)→ 返回 TRUE（不是报错或 NULL） - 子查询全为
NULL：SELECT 100 > ALL (SELECT NULL UNION SELECT NULL)→ 返回 UNKNOWN（即条件不成立） - 验证方式：用
SELECT ... WHERE (condition) IS TRUE显式判断，避免依赖默认布尔语义
真正难处理的不是语法，而是子查询数据质量不可控时，ALL 的三值逻辑（TRUE/UNKNOWN/FALSE）会让结果漂移得毫无征兆。
