先捋清楚一个核心概念：ANY 和 ALL 本质上就是标量与集合之间的比较逻辑，必须配合 =、>、< 这些比较运算符一起用。ANY 代表“满足集合中任一元素即可”（逻辑 OR），ALL 则要求“满足集合中所有元素”（逻辑 AND）。这个区别看似简单，实际用起来稍不留神就会掉坑。
ANY 和 ALL 的本质是「标量 vs 集合」的比较逻辑
它们并不是什么独立的函数，而是附着在 =、>、< 等比较运算符上的“修饰词”，作用对象必须是子查询返回的单列结果集。很多人写 WHERE col = ANY(...) 时以为这是标准写法——没错，= ANY 等价于 IN，但 > ANY 和 > ALL 的行为可就完全不一样了。
关键判断点很清楚：ANY 只要集合里有一个元素满足条件就算通过，ALL 则必须全部满足才行。举个例子：
> ANY (1, 3, 5)→ 等价于> 1，因为只要比最小值大就成立> ALL (1, 3, 5)→ 等价于> 5，必须比最大值还要大= ANY (1, 3, 5)→ 等价于IN (1, 3, 5)，但这里有个容易忽略的坑：如果子查询里包含 NULL，= ANY会返回 UNKNOWN，而IN同样不匹配 NULL——两者在 NULL 处理上其实是一致的
子查询必须返回单列，且类型兼容
如果子查询返回多列，数据库会直接翻脸。PostgreSQL 会报 ERROR: more than one field in subquery，MySQL 则报 Operand should contain 1 column(s)。类型不兼容时（比如拿字符串和数字比较），多数引擎会试着隐式转换，但转换结果经常不可靠，建议别这么干。
- 子查询只 SELECT 一个字段：比如
SELECT price FROM products WHERE category = 'book' - 子查询里别用
*或罗列多个字段：SELECT id, name FROM users不能直接用在ANY后面 - 数值字段拿字符串子查询要小心：
salary > ANY (SELECT '10000' UNION SELECT '20000')可能触发隐式转换，最好显式CAST一下，或者统一数据类型
NULL 值会让 ANY/ALL 返回 UNKNOWN 而非 TRUE/FALSE
这才是最容易踩的雷。SQL 的三值逻辑下，任何与 NULL 的比较结果都是 UNKNOWN，而 WHERE 子句只保留 TRUE 的行，UNKNOWN 相当于被静默过滤掉——你可能还纳闷为什么数据明明符合条件却没出来，其实逻辑已经被 NULL 搞没了。
- 假设子查询返回
(1, 2, NULL)，那么col > ANY (subquery)永远不成立。因为col > NULL是 UNKNOWN，整个表达式就是 UNKNOWN - 同理，
col = ANY (subquery)在子查询含 NULL 时也不会匹配任何行，即使col恰好等于 1 或 2 - 安全做法：显式排除 NULL，比如
col > ANY (SELECT price FROM items WHERE price IS NOT NULL)
性能提示：ALL 通常比 ANY 更重，尤其配合子查询时
数据库优化器对 ANY 常常能转化为半连接（semi-join）或者直接走索引查找，但 ALL 需要确认“全部满足”，往往得全表扫描或排序。特别是 < ALL 或 > ALL，本质上等价于和聚合值做比较，手动改写一下往往更快。
- 把
salary > ALL (SELECT salary FROM managers)改成salary > (SELECT MAX(salary) FROM managers)，语义完全一致，执行效率却高出一截 - 把
id NOT IN (SELECT id FROM archived)改成NOT EXISTS (SELECT 1 FROM archived a WHERE a.id = t.id)，还能顺便避开 NULL 导致的空结果问题 - PostgreSQL 里
ANY配合数组字面量（比如status = ANY(ARRAY['pending','draft'])）走索引很高效；但 MySQL 不支持数组字面量，只能用子查询或IN
说到底，ANY 和 ALL 的威力在于表达“相对于集合的极值条件”，但它们不像 IN 或 EXISTS 那么直观。一旦子查询里出现 NULL、多列，或者类型不匹配，结果就很容易偏离预期。动手前先确认子查询的结果集是否干净、单列、无 NULL，这步省不得。
