ALL和ANY语义完全相反：ANY表示“存在一个满足即可”（等价OR链），ALL表示“全部满足才成立”（等价AND链）；二者在NULL、空子查询及数据库版本间行为差异显著，误用易致结果错误或执行计划失控。
ALL 和 ANY 语义完全相反，不是“差不多”，写错一个字就可能让查询返回空集、全表扫描，甚至在 NULL 或空子查询时行为彻底失控。
ANY 表示“存在一个满足即可”，等价于 OR 链
比如 > ANY (SELECT age FROM student WHERE sex = 'girl') 实际展开为：age > 18 OR age > 20 OR age > 19（假设子查询返回这三个值）。只要比其中任意一个女生年龄大，整行就保留。
-
= ANY就是IN的等价写法，如id = ANY(ARRAY[1,2,3])在 PostgreSQL 中合法，但 MySQL 不支持数组字面量，必须改用id IN (1,2,3) -
!= ANY容易误用：它不表示“不属于集合”，而是“不等于集合中至少一个值”——比如5 != ANY(ARRAY[5,6])返回 true（因为 5 ≠ 6），这和业务直觉相悖 - 性能上，
> ANY通常能触发索引范围扫描（优化器可能重写为> MIN(...)），但别依赖自动优化，先看EXPLAIN
ALL 表示“全部满足才成立”，等价于 AND 链
> ALL (SELECT age FROM student WHERE sex = 'girl') 展开后是：age > 18 AND age > 20 AND age > 19，即等价于 age > 20（大于最大值）。
-
= ALL极少见，仅当子查询只返回单值时有意义；若返回多行，恒为 false，大概率是误写 -
!= ALL看似像NOT IN，但二者在 NULL 场景下都失效：只要子查询含NULL，!= ALL永远返回 UNKNOWN → 整行被过滤。安全做法是显式加WHERE age IS NOT NULL - MySQL 8.0+ 对
ALL子查询做了下推优化，但老版本可能走嵌套循环；查大表前务必EXPLAIN确认执行计划
空子查询和 NULL 是最危险的边界情况
SQL 标准规定：任何与 NULL 的比较结果都是 UNKNOWN，而 WHERE 只接受 TRUE。
- 子查询返回任意一个
NULL，> ANY()就变成UNKNOWN OR ...→ 整体UNKNOWN→ 该行被过滤 -
> ALL()遇到NULL时，变成TRUE AND UNKNOWN→ 整体UNKNOWN→ 同样被过滤 - 更隐蔽的是空子查询：PostgreSQL 中
> ALL(EMPTY)返回TRUE（数学上“全称命题对空集恒真”），而 MySQL 返回空结果集 —— 同一条 SQL 在不同库行为不一致
真正难的不是记住“ANY 是 OR，ALL 是 AND”，而是每次写的时候都得问自己：子查询会不会为空？会不会有 NULL？目标数据库怎么处理空集？这些细节在生产环境里一碰就出问题，且很难复现。
