子查询在WHERE中作过滤条件需严格匹配返回类型：标量子查询（单值）用于=、>等比较运算符，集合子查询（多值）须用IN/EXISTS，行子查询（单行多列）用=或IN；务必防范NULL陷阱与相关子查询性能问题。
子查询在 WHERE 中用作过滤条件是常见需求，但直接套用嵌套 SELECT 很容易报错——关键看子查询返回的是单值、多值还是行集，类型不匹配就会触发 Subquery returns more than 1 row 或 Operand should contain 1 column(s) 这类错误。
子查询必须返回单列单行才能用 =、!=
当你写 WHERE salary = (SELECT MAX(salary) FROM employees)，括号里的子查询必须只返回一个值。如果表里有多个员工并列最高薪，这条语句就失败。
- 确保子查询加了
LIMIT 1或聚合函数（如MAX()、MIN()、AVG()）来强制单值 - 避免在子查询中漏写
WHERE条件导致意外多行，例如(SELECT id FROM users)几乎总是错的 - 数据库对空结果的处理不同：MySQL 返回
NULL，可能使整个条件为UNKNOWN；PostgreSQL 同样，但行为更严格
多值场景必须用 IN、NOT IN 或 EXISTS
IN 是最直观的替代方案，但要注意 NULL 带来的陷阱：如果子查询结果含 NULL，col IN (1,2,NULL) 永远不成立；NOT IN 更危险，只要子查询返回任意 NULL，整条语句结果恒为空。
- 用
IN时加WHERE col IS NOT NULL过滤子查询结果，例如：WHERE dept_id IN (SELECT id FROM departments WHERE id IS NOT NULL) -
EXISTS更安全、通常也更快，尤其适合“是否存在关联记录”类判断，例如：WHERE EXISTS (SELECT 1 FROM orders o WHERE o.user_id = users.id) - 别用
NOT IN处理可能含NULL的字段，改用NOT EXISTS
相关子查询要小心性能和语义错误
当子查询引用外部查询的列（比如 WHERE salary > (SELECT AVG(salary) FROM employees e2 WHERE e2.dept = employees.dept)），它就成了“相关子查询”，会为外部每一行执行一次。这很容易拖慢查询，也可能因别名或作用域问题报错。
- 检查是否漏写表别名，导致列名歧义，例如
employees.dept在子查询里没声明employees别名就无法访问 - 相关子查询不能出现在
GROUP BY或聚合函数内部，MySQL 8.0+ 允许部分场景，但旧版本直接拒绝 - 若逻辑上只需一次计算（比如全表平均薪资），就不要写成相关子查询，提取到
FROM子句或用 CTE 更清晰
最常被忽略的是子查询的 NULL 行为和相关性边界——不是所有数据库都允许子查询引用外部 ORDER BY 或 LIMIT 中的列，也不是所有 IN 都能自动去重；写完务必用小数据集验证结果是否符合预期，而不是只看有没有语法错误。
