子查询无法解决不确定嵌套层级的分销统计问题，因其仅支持单跳映射、不支持树形遍历，强行多层in嵌套会导致逻辑断裂、结果不可靠，甚至在mysql 8.0+/postgresql中静默返回空。
直接说结论：子查询无法解决“不确定嵌套层级”的分销统计问题——它天生不支持树形遍历，强行用多层 IN 嵌套只会导致逻辑断裂、结果不可靠，甚至在 MySQL 8.0+/PostgreSQL 中静默返回空。
为什么子查询处理不了不确定层级的分销关系
分销网络本质是父子递归结构（A发展B，B发展C，C发展D……深度未知），而子查询只做单跳映射：
-
WHERE user_id IN (SELECT referrer_id FROM users WHERE level = 1)只能筛出一级下线 - 再套一层
WHERE user_id IN (SELECT user_id FROM users WHERE referrer_id IN (...))看似能到二级，但一旦某中间节点无下线，整条链就断，且无法区分是“没发展人”还是“数据缺失” - MySQL 5.7 允许三层
IN嵌套但不保证语义正确；MySQL 8.0+ 和 PostgreSQL 在优化阶段可能直接剪枝，返回空结果而不报错
真正可用的方案只有两种：递归 CTE 或固定层数自连接
必须先明确你的数据库版本和最大可能深度：
- MySQL 8.0+ / PostgreSQL / SQL Server：用
WITH RECURSIVE，显式定义锚点（顶层推广员）和递归成员（找直接下线） - MySQL 5.7 或需兼容旧系统：最多支持 3–4 层自连接，例如
JOIN users u2 ON u1.id = u2.referrer_id JOIN users u3 ON u2.id = u3.referrer_id，但超过 4 层性能急剧下降且难维护 - 不要试图在递归 CTE 外再套子查询做聚合——先让 CTE 输出完整路径（含
level和root_id），再在外层GROUP BY root_id, level统计
子查询唯一能安全参与的环节：预聚合或条件过滤
它不该出现在遍历路径中，但可用来准备干净输入：
- 用子查询提前筛出有效根节点：
(SELECT id FROM users WHERE is_promoter = 1 AND status = 'active')，再把这个结果集喂给 CTE 的锚点部分 - 统计每个推广员的直推人数（一级）可以用子查询：
(SELECT COUNT(*) FROM users u2 WHERE u2.referrer_id = u1.id)，这是标量、单跳、无层级依赖 - 若要算“某推广员所有下线总业绩”，必须先用 CTE 展开全路径，再
JOIN order汇总，不能把JOIN order放进子查询里——否则每行都触发一次大表扫描
最容易被忽略的坑：NULL 和层级截断
递归 CTE 默认有深度限制（MySQL 8.0 是 1000，PostgreSQL 是 100），超深分销链会直接被截断，且不报错；更隐蔽的是 NULL 传播：
- 如果某用户
referrer_id是NULL，CTE 锚点不会包含他，但若你用LEFT JOIN补全路径，level字段可能为NULL，后续GROUP BY level会把所有断链用户归到同一组 - 子查询里漏掉
AS别名（如(SELECT ...)没命名）会导致 MySQL 8.0+ 直接报ERROR 1248，而这个错误常被误判为逻辑问题 - 真正复杂点不在怎么写，而在验证：每一层的
COUNT(*)是否符合业务预期？比如一级下线数是否等于referral_count字段？断链用户是否真的应被排除？
