子查询在where中用=比较多列时应改用exists；因=要求单值，而多列子查询语义冲突，exists仅判断存在性且忽略列数，最稳妥。

子查询在 WHERE 中用了 = 却返回多列？立刻换 EXISTS

错误现象是 MySQL 报 Subquery returns more than 1 row，PostgreSQL 报 more than one row returned by a subquery used as an expression——但其实问题可能更早：你试图用 = 去比较一个返回两列（比如 id, name）的子查询，数据库连“比哪一列”都无从判断，直接拒绝执行。

这不是数据量问题，是语法层面的语义冲突。解决方式不是压行数，而是换操作符：

• 想判断“是否存在匹配记录”，用 EXISTS：它完全忽略子查询返回哪些列，只看有没有结果行
• 别写 WHERE (id, name) = (SELECT id, name FROM ...)——多数数据库不支持多列等值比较（MySQL 8.0+ 支持行构造器，但 PostgreSQL 需用 ROW() 包裹，且仍受限于单行）
• 若真要靠多列联合判断存在性，EXISTS 最稳：WHERE EXISTS (SELECT 1 FROM orders o WHERE o.customer_id = c.id AND o.status = 'shipped')

子查询在 FROM 中返回多列？必须起别名

MySQL 强制要求每个派生表（即 FROM 里的子查询）带别名，否则报 Every derived table must have its own alias；PostgreSQL 虽允许省略，但不加别名会导致外层无法引用列。

常见错误写法：SELECT * FROM (SELECT user_id, MAX(created_at) FROM logs GROUP BY user_id)——没别名，MySQL 直接报错；即使能过，你也无法在 SELECT 列表里写 t.max_created 这类引用。

正确做法：

• 给子查询加别名：SELECT t.user_id, t.last_login FROM (SELECT user_id, MAX(created_at) AS last_login FROM logs GROUP BY user_id) AS t
• 别名后必须用点号显式引用列，不能依赖位置或隐式命名
• 如果子查询里用了聚合函数（如 MAX()），记得 GROUP BY 字段必须和非聚合列一致，否则 PostgreSQL 会报错，MySQL 在严格模式下也会

SELECT 列表里嵌套子查询返回多列？语法不通过，别这么写

标准 SQL 明确禁止在 SELECT 列表中使用返回多列或多行的子查询。例如：SELECT name, (SELECT id, email FROM contacts WHERE user_id = u.id) FROM users u——MySQL 和 PostgreSQL 都会直接报语法错误，不是运行时报错，是解析阶段就拒掉。

这种写法没有绕过方案。你必须重构逻辑：

• 改用 LEFT JOIN：把多列需求“拉平”到主查询层级，SELECT u.name, c.id, c.email FROM users u LEFT JOIN contacts c ON c.user_id = u.id
• 若需一对多展开（如一个用户对应多个邮箱），用聚合函数拼接：SELECT u.name, GROUP_CONCAT(c.email) FROM users u LEFT JOIN contacts c ON c.user_id = u.id GROUP BY u.id
• PostgreSQL 可用 LATERAL 实现每行驱动一次子查询并返回多列，但仍是单行输出，不是“一行变多行”

误把多列子查询当 IN 的右侧？检查括号和逗号

写 WHERE (a, b) IN (SELECT x, y FROM t) 看似合理，但要注意：

• MySQL 5.7+ 支持这种行构造器语法，但要求左右两边列数、类型、顺序严格一致
• PostgreSQL 必须显式写成 WHERE ROW(a, b) IN (SELECT x, y FROM t)，漏掉 ROW() 就报错
• Oracle 不支持该语法，得拆成两个独立条件：WHERE a IN (SELECT x FROM t) AND b IN (SELECT y FROM t)（注意：这语义不同，慎用）
• 最稳妥的替代是 EXISTS + 关联：WHERE EXISTS (SELECT 1 FROM t WHERE t.x = a AND t.y = b)

多列子查询最容易被忽略的坑，是以为“只要列数对得上就能塞进任何上下文”。实际上，每个位置对返回结构的要求完全不同：WHERE 里要布尔值，SELECT 列表里要标量，FROM 里要虚拟表——强行混用，错的不是数据，是语法契约本身。