标量子查询中用distinct无法解决一对多重复问题，因其不允许多行返回；exists适合存在性判断且不放大主表行数；取代表值应优先用lateral或聚合；相关子查询需索引优化性能。
子查询里用 DISTINCT 不能解决一对多导致的重复行问题
很多人一看到主表查出来重复数据，就下意识在子查询里加 DISTINCT，比如：
SELECT a.id, a.name, (SELECT DISTINCT b.status FROM orders b WHERE b.user_id = a.id) AS status FROM users a;这会直接报错——MySQL/PostgreSQL 都不允许子查询返回多行结果给标量子查询。即使改成
IN 或 = ANY，DISTINCT 也只去重子查询内部结果，不控制主表行数。真正的问题不在“子查询有没有重复值”，而在“子查询是否被当作关联条件使用”。用 EXISTS 判断存在性，天然规避重复行
EXISTS 子查询只关心“有没有匹配行”，不取任何字段值，也不会放大主表行数。它适合表达“用户是否有订单”“商品是否被收藏过”这类布尔型需求：
SELECT u.id, u.name FROM users u WHERE EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id AND o.status = 'paid');
-
EXISTS内部可以写任意复杂条件，但建议只保留关联字段 + 业务过滤（如status = 'paid'），避免拖慢性能 - 不要在
EXISTS里写SELECT *，写SELECT 1或SELECT NULL更清晰，优化器也更容易跳过字段解析 - 如果需要多个存在性判断（如“有未发货订单”且“有已评价订单”），用多个
EXISTS并列比JOIN更安全——不会因某一方无匹配而丢主表数据
需要取一对多中的某个代表值？优先用 LATERAL 或聚合，别硬套子查询
当你要取“每个用户的最新订单时间”或“首个订单状态”，强行用标量子查询容易出错：
-- 危险！可能随机返回某一行，且无索引时极慢 SELECT u.id, (SELECT b.created_at FROM orders b WHERE b.user_id = u.id ORDER BY b.created_at DESC LIMIT 1) FROM users u;
- MySQL 8.0+ / PostgreSQL 支持
LATERAL，能正确关联并限制子查询范围：SELECT u.id, l.latest_time FROM users u LEFT JOIN LATERAL (SELECT MAX(created_at) AS latest_time FROM orders b WHERE b.user_id = u.id) l ON true; - 老版本可用聚合 +
LEFT JOIN替代，但注意GROUP BY必须覆盖主表所有SELECT字段，否则 MySQL 5.7 严格模式会报错 - 避免在子查询里用
ORDER BY ... LIMIT 1配合非唯一排序字段（如只有created_at），可能出现不确定结果
性能陷阱：相关子查询在大表上可能全表扫描多次
EXISTS 和标量子查询都是“相关子查询”，即每处理主表一行，就执行一次子查询。如果 users 有 10 万行，orders 有 50 万行，且 orders.user_id 没索引，就会触发 10 万次全表扫描。
- 必须确保子查询中的关联字段（如
o.user_id）有索引，最好是复合索引（如(user_id, status)） - 用
EXPLAIN看执行计划，重点确认子查询部分是否显示Using index condition或Using where; Using index - 当数据量大且逻辑允许时，用
JOIN + GROUP BY预聚合，再和主表LEFT JOIN，通常比反复执行子查询快一个数量级
DISTINCT 都没用。
