子查询中用group_concat可避免一对多导致的行膨胀，但需注意长度限制、null处理及仅适用于展示；判断存在性应优先用exists而非in；子查询必须确保单行返回，否则报错或结果不可靠；去重须从逻辑源头解决，而非依赖distinct。
子查询里用 GROUP_CONCAT 合并多条明细
一对多查出来重复，本质是主表一行被子表多行“撑开”了。直接去重会丢数据，而 GROUP_CONCAT 能把子表的多值压成一个字符串字段，避免结果膨胀。比如查用户和其所有订单号：
SELECT u.id, u.name, (SELECT GROUP_CONCAT(o.order_no) FROM orders o WHERE o.user_id = u.id) AS order_nos FROM users u;
注意点：
-
GROUP_CONCAT默认用逗号分隔，超长会被截断（MySQL 默认 1024 字符），可提前设GROUP_CONCAT_MAX_LEN - 若子表无匹配记录，该字段返回
NULL，不是空字符串 - 不适用于需要后续按单个订单号做条件过滤的场景——它只是展示用
用 EXISTS 替代 IN 避免 NULL 导致全空结果
当子查询用于判断“是否存在关联记录”时，别写 WHERE id IN (SELECT user_id FROM orders)。只要 orders.user_id 里有 NULL，整个条件就恒为 UNKNOWN，结果集为空——这不是 bug，是 SQL 标准行为。
改用 EXISTS 更稳：
SELECT u.name FROM users u WHERE EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id);
关键差异：
-
EXISTS不比较值，只检查子查询是否返回至少一行，天然跳过NULL影响 - 多数数据库对
EXISTS的执行计划更优，尤其子表大、主表小时 -
NOT IN比NOT EXISTS更危险：子查询只要出一个NULL，整条语句就查不到任何数据
子查询内部必须限制行数，否则主查询报错或逻辑错乱
如果子查询本应只返回一行（比如“最新一笔订单金额”），但没加 LIMIT 1 或聚合，MySQL 会直接报错 Subquery returns more than 1 row；其他数据库可能静默取第一行，导致结果不可靠。
正确写法分两种场景：
- MySQL 8.0+ / PostgreSQL：优先用窗口函数在子查询内排序编号，再过滤
- 老版本 MySQL：用
(SELECT amount FROM orders WHERE user_id = u.id ORDER BY created_at DESC LIMIT 1)
错误示范（看似简洁，实则危险）：
SELECT u.name, (SELECT amount FROM orders WHERE user_id = u.id ORDER BY created_at DESC) FROM users u;
这里漏了 LIMIT 1，一旦某用户有多笔订单，子查询就返回多行，主查询直接失败。
去重不能靠外层 DISTINCT，得从子查询逻辑源头解决
很多人看到结果重复，第一反应是加 DISTINCT。但如果是主表和子表 JOIN 后出现的“假重复”，DISTINCT 只是掩盖问题——它把三条明细撑开的三行“订单信息”强行合并，但你根本不知道哪条明细被保留了。
真正要做的，是确认业务意图：
- 如果只需要知道“有没有订单”，用
EXISTS最轻量 - 如果要汇总统计（如订单数、总金额），用
LEFT JOIN + GROUP BY显式分组 - 如果要取每用户的最新一条明细，必须在子查询或 JOIN 后用窗口函数/自连接控制行数
最易被忽略的一点：子查询返回多列时，IN 完全不支持，必须换 JOIN 或相关子查询——这时候“去重”的责任就落在 JOIN 条件和分组逻辑上，而不是 DISTINCT。
