应根据业务需求选择：若仅过滤用EXISTS或DISTINCT，关联时用GROUP BY聚合或ROW_NUMBER()拍平，标量子查询适用于取单值且需报错控制。
子查询去重：用 SELECT DISTINCT 还是 GROUP BY？
直接用子查询本身不会自动去重，重复行来自主表和子查询结果的笛卡尔式关联。关键不是“子查询要不要去重”，而是你希望保留哪一行——是最新的一条、数值最大的一条，还是任意一条。
常见错误是写成：SELECT * FROM orders WHERE customer_id IN (SELECT customer_id FROM customers WHERE region = 'CN')，看似没问题，但如果 customers 表里一个 customer_id 出现多次（比如历史数据没清理），IN 仍会返回重复 orders 行（取决于优化器是否自动 dedup）。
- 如果子查询只用于过滤（
IN/EXISTS），重复值不影响结果逻辑，但可能轻微拖慢执行——建议子查询加DISTINCT或改用EXISTS - 如果子查询用于关联（
JOIN或列级子查询），必须显式控制返回行数，否则一对多直接爆炸 -
GROUP BY在子查询里更可控，尤其当你需要聚合字段（如最新订单时间）时；DISTINCT更轻量，但只能去整行重复
关联一对多时，用标量子查询只取单值
当主表每行需对应子表“某个代表值”（如每个客户的最新订单ID），标量子查询最安全——它强制只返回0或1行，超出会报错，逼你处理逻辑。
例如：SELECT c.name, (SELECT order_id FROM orders o WHERE o.customer_id = c.id ORDER BY created_at DESC LIMIT 1) AS latest_order_id FROM customers c
- PostgreSQL/MySQL 8.0+ 支持
LIMIT，SQLite 也支持；但旧版 MySQL 需用变量或自连接模拟 - 如果子查询可能无结果，标量值为
NULL，符合预期；若想报错中断，加WHERE ... IS NOT NULL后置校验 - 性能隐患：对主表每行都执行一次子查询，大数据量时比
JOIN + ROW_NUMBER()慢得多
用 ROW_NUMBER() 配合子查询预过滤
真正高效且可控的方式，是把一对多关系在子查询里先“拍平”——用窗口函数标记序号，再外层筛选序号=1的行。
示例（获取每个客户的首笔订单）：
SELECT c.name, o.order_id, o.amount
FROM customers c
JOIN (
SELECT customer_id, order_id, amount,
ROW_NUMBER() OVER (PARTITION BY customer_id ORDER BY created_at) AS rn
FROM orders
) o ON c.id = o.customer_id AND o.rn = 1
-
PARTITION BY是分组依据，ORDER BY决定“第一行”是谁——按时间、金额、ID 都可以 - 注意：不同数据库对
ROW_NUMBER()的支持一致，但RANK()和DENSE_RANK()在并列时行为不同，别混用 - 如果子查询里有
WHERE条件（如只查2023年订单），务必放在窗口函数前，否则可能漏掉本该排第一的行
小心 EXISTS 和 IN 的语义差异
很多人以为 IN 和 EXISTS 可以互换去重，其实它们处理空值和性能逻辑完全不同。
比如：SELECT * FROM orders WHERE customer_id IN (SELECT id FROM customers WHERE status = 'active')，如果子查询返回 NULL（比如 id 字段允许为空且恰好有空值），整个 IN 表达式结果为 UNKNOWN，该行被过滤掉——这常被当成“意外去重”。
-
EXISTS不受NULL影响，只关心是否存在匹配行；语义更清晰，推荐优先用 -
IN在子查询结果少时可能走哈希查找，EXISTS常走半连接，实际性能要看数据分布和索引 - 子查询若含
OR、LIKE等非SARGable条件，EXISTS通常更容易利用索引
真正麻烦的不是语法怎么写，而是你想表达的业务逻辑是否被准确建模——比如“每个客户最新订单”在并发写入下可能瞬间过期，“首笔订单”在数据修复后可能变味。子查询只是工具，拍平一对多的前提，是你先确认“多”里面哪一个是你要的那个“一”。
