子查询需注意括号、单值约束、别名及执行时机：WHERE中用=需单行返回，多值用IN，存在性用EXISTS；FROM中子查询必须加括号并起别名；SELECT中嵌套子查询易致性能问题，应优先JOIN聚合；相关子查询逐行执行，慎用。
子查询写在 WHERE 里，但括号不能漏、SELECT 必须带列名
子查询最常见的错误是 WHERE user_id = (SELECT id FROM users) 这种写法——它会报错 Subquery returns more than 1 row。不是语法错了，而是语义冲突：等号右边只能返回单个值，但子查询可能返回多行。
正确做法取决于你要做什么：
- 查单个值（比如某个用户的最新订单ID）：
WHERE order_id = (SELECT MAX(id) FROM orders WHERE user_id = 123)，确保子查询用MAX/MIN/LIMIT 1等约束为一行一列 - 查多个值（比如所有 VIP 用户下的订单）：
WHERE user_id IN (SELECT id FROM users WHERE level = 'vip')，改用IN，这是最自然的匹配方式 - 判断存在性（比如有没有未支付订单）：
WHERE EXISTS (SELECT 1 FROM orders WHERE user_id = u.id AND status = 'pending')，EXISTS不关心返回什么，只看有没有结果，性能通常更好
FROM 子句里的子查询必须起别名，否则 MySQL 直接报错
想把子查询当临时表用？比如统计每个用户最近一条订单的时间，再和用户表 JOIN。这时候你得写成 FROM (SELECT user_id, MAX(created_at) AS last_time FROM orders GROUP BY user_id) AS recent_orders。
关键点就两个：
- 子查询外层必须加括号，否则解析失败
- MySQL 强制要求给这个临时结果集起别名（哪怕只是
AS t），否则报错Every derived table must have its own alias - 别名之后才能在
SELECT或JOIN中引用字段，比如recent_orders.last_time
SELECT 列表里嵌套子查询很慢，尤其没索引时
有人喜欢这么写：SELECT name, (SELECT COUNT(*) FROM orders WHERE orders.user_id = users.id) AS order_count FROM users。逻辑清晰，但每查一个用户，就执行一次子查询——1000 个用户，就是 1000 次全表扫描（如果 orders.user_id 没索引）。
更稳的做法是先聚合再 JOIN：
- 用
LEFT JOIN+GROUP BY替代：SELECT u.name, COUNT(o.id) AS order_count FROM users u LEFT JOIN orders o ON u.id = o.user_id GROUP BY u.id, u.name - 如果只是想过滤（比如只看有订单的用户），优先用
INNER JOIN，比在WHERE里套子查询快得多 - 子查询在
SELECT列表里无法利用外部查询的索引优化，执行计划里常显示为DEPENDENT SUBQUERY，这就是性能告警信号
相关子查询容易被当成普通子查询，实际是逐行计算
像 SELECT * FROM users WHERE id = (SELECT user_id FROM logs WHERE action = 'login' ORDER BY time DESC LIMIT 1) 是“不相关子查询”——它只执行一次；但 SELECT *, (SELECT MAX(time) FROM logs l WHERE l.user_id = u.id) AS last_login FROM users u 就是“相关子查询”，u.id 是外部表字段，意味着对 users 表每一行，都要重新跑一遍子查询。
这种写法不是错，但代价高，且容易误判执行逻辑：
- 确认是否真需要逐行计算——有时用窗口函数（如
MAX(time) OVER (PARTITION BY user_id)）或预聚合更合适 - 相关子查询在 PostgreSQL/SQL Server 中支持较好，但某些旧版 MySQL 对它的优化很弱
- 用
EXPLAIN看执行计划时，注意select_type字段：如果是DEPENDENT SUBQUERY，就得小心了
子查询看着简单，但括号位置、返回行数、别名规则、执行时机这四点，任何一个没对上，轻则结果错，重则查十分钟没响应。尤其是从应用代码里拼 SQL 时，很容易忽略外部变量是否被正确注入到相关子查询里——那里没有报错，只有沉默的慢。
