子查询不能表达行为顺序，仅适用于前置过滤、去重或分步聚合；必须配合窗口函数或自连接才能实现“谁先谁后”的时序逻辑。
纯子查询无法直接建模行为顺序，必须配合窗口函数或自连接才能表达“谁先谁后”。子查询只适合做前置过滤、去重或分步聚合，不能替代 ROW_NUMBER() 或 LAG() 的序列定位能力。
子查询能做什么：提前筛用户、去重、定义阶段人群
子查询在漏斗中真正管用的场景是“划定起点”或“锁定目标人群”，比如只分析完成过浏览的用户后续行为，或排除测试账号。它不负责判断顺序，只负责缩小数据集范围。
- 用子查询提取“有浏览行为的用户集合”，再在外层查这些用户的加购/支付记录：
SELECT COUNT(*) FROM events WHERE user_id IN (SELECT DISTINCT user_id FROM events WHERE event_type = 'view') - 若第一步要求“首次浏览”，需先用窗口函数算出每个用户的首条
view时间，再用子查询取这批用户——子查询本身不计算“首次”，只是搬运结果 - 避免在子查询里写
WHERE event_type IN ('view', 'cart')后直接COUNT，这和CASE WHEN一样丢失时序，仍会把先加购后浏览的用户计入转化
子查询不能做什么：代替时间排序、跳过中间步骤、验证时间窗口
常见错误是以为嵌套一层子查询就能隐式保证顺序。实际上，只要没显式 PARTITION BY user_id ORDER BY event_time，任何子查询返回的行都是无序的，LEAD() 或 LAG() 在外层也拿不到正确上下文。
-
SELECT * FROM (SELECT * FROM events WHERE event_type IN ('view','cart') ORDER BY event_time) t—— 缺少PARTITION BY user_id，跨用户混序，漏斗路径全乱 - 想用子查询“跳过加购直接看浏览→支付”，写成
WHERE user_id IN (SELECT user_id FROM events WHERE event_type = 'view') AND event_type = 'pay'—— 这只统计了“既有浏览又有支付”的用户数，完全不反映这两件事是否发生在同一次会话、是否先后发生 - 时间窗口（如“10分钟内完成下一步”）必须在窗口函数层计算差值，子查询只能传入固定时间点，无法动态比对相邻事件
何时必须放弃子查询，改用窗口函数+条件过滤
只要漏斗定义里含“紧接着”“之后”“在X时间内”这类词，子查询就该让位。这时候核心逻辑不在“选哪些人”，而在“对每个人的时间线做状态推进”。
- 真实路径匹配（如
view → cart → buy）：用ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY event_time)打序号，再自连接或用LEAD(event_type, 1)和LEAD(event_type, 2)分别取下一项和下两项，最后WHERE精确匹配类型序列 - 柔性漏斗（如“浏览后任意动作都算进入下一阶段”）：需聚合级操作，例如
MIN(event_time) FILTER (WHERE event_type = 'cart' OR event_type = 'fav')（PostgreSQL），子查询无法表达这种带条件的聚合下推 - ClickHouse 用户直接用
windowFunnel(600)，它内部是状态机，不是 SQL 层的子查询或窗口函数可模拟的
最容易被忽略的是：子查询的结果集一旦脱离了原始时间戳上下文，就再也无法重建用户行为链。哪怕你在外层加 ORDER BY event_time，也只是全局排序，不是每个用户的独立时间轴。这点在千万级用户行为表中会导致漏斗口径漂移，且难以排查。
