ALL要求全部满足（逻辑AND），ANY只需任一满足（逻辑OR）；二者语义相反，且受NULL和空子查询影响显著，误用易致结果错误。
ALL 和 ANY 不是“差不多”，它们的语义完全相反，用错一个字符就可能让查询结果变成空集或全表扫描。
ANY 表示“存在一个满足即可”，逻辑等价于 OR 链
当你写 > ANY (SELECT age FROM student WHERE sex = 'girl')，实际效果是：age > 18 OR age > 20 OR age > 19（假设子查询返回 18, 20, 19）。只要比其中任意一个女生年龄大，整行就保留。
- 常见错误：误以为
= ANY是“模糊匹配”，其实它就是IN的等价写法，比如id = ANY(ARRAY[1,2,3])等同于id IN (1,2,3) - PostgreSQL 支持数组字面量配合
= ANY，但 MySQL 不支持，得改用IN - 性能上，
> ANY可能触发索引范围扫描；而实际等价于 <code>，优化器有时能自动重写，但别依赖
ALL 表示“全部满足才成立”，逻辑等价于 AND 链
> ALL (SELECT age FROM student WHERE sex = 'girl') 展开后是：age > 18 AND age > 20 AND age > 19，也就是 age > 20（即大于最大值）。它要求比子查询里每一个值都大。
- 最容易踩的坑：
!= ALL不等于NOT IN—— 如果子查询结果含NULL，!= ALL永远返回 false，而NOT IN同样失效；两者都得加IS NOT NULL过滤 -
= ALL极少见，仅当子查询只返回单值时才有意义（否则恒为 false），多数情况是误写 - MySQL 8.0+ 对
ALL子查询做了下推优化，但老版本可能走嵌套循环，查大表前先EXPLAIN看执行计划
NULL 值会让 ALL/ANY 行为彻底失控
SQL 标准规定：任何与 NULL 的比较结果都是 UNKNOWN，而 WHERE 只接受 TRUE。这意味着：
- 只要子查询返回任意一个
NULL，> ANY(...)就变成UNKNOWN OR ...→ 整体为UNKNOWN→ 该行被过滤 -
> ALL(...)遇到NULL时，变成TRUE AND UNKNOWN→ 整体为UNKNOWN→ 同样被过滤 - 安全做法永远是显式排除：
WHERE x > ALL(SELECT age FROM t WHERE age IS NOT NULL)
真正难的不是记住“ANY 是 or，ALL 是 and”，而是意识到：子查询是否为空、是否含 NULL、数据库对空集的处理（如 PostgreSQL 中 > ALL(EMPTY) 返回 true，MySQL 返回 empty set），这些边界情况在生产环境里一碰就出问题。
