真正能落地的漏斗分析必须用窗口函数打序、标记路径、控制时间窗；presto中lag/lead需严格partition by user_id且order by event_time, event_id，否则跨用户错配；首行lag为null须显式过滤；多步漏斗宜用row_number()+自连接并加时间约束。
在 Presto（Trino）中做漏斗分析，不能靠 CASE WHEN + COUNT DISTINCT 硬凑——那样只算“有没有”，不算“谁先谁后”“间隔多久”，结果不可信；真正能落地的方案，必须用窗口函数打序、标记路径、控制时间窗，且要避开 Presto 特有的执行陷阱。
为什么 Presto 的 LAG/LEAD 容易返回 NULL 或错配？
Presto 对 LAG() 和 LEAD() 的行为严格依赖 PARTITION BY 和 ORDER BY 的组合完整性。漏掉任一，就会跨用户匹配。
- 必须同时写
PARTITION BY user_id和ORDER BY event_time, event_id：只写event_time会导致同秒多事件排序不稳定，LAG()可能抓到隔壁用户的上一行 -
event_id是硬性推荐字段：Presto 不保证毫秒级event_time的唯一性，缺它就等于放弃顺序可靠性 - 首行
LAG()必为NULL，但 Presto 不会报错，也不会跳过——直接参与WHERE判断会静默丢数据，得显式加AND prev_type IS NOT NULL - 别在
WHERE里过滤event_type后再套窗口：Presto 会先全量排序再过滤，10亿行表可能 OOM；应先WHERE event_type IN ('view', 'add_to_cart', 'pay')，再OVER
怎么用 ROW_NUMBER() + 自连接实现三步以上漏斗？
两步用 LAG() 足够轻量，但「浏览 → 加购 → 下单 → 支付」这种四步链路，硬套多层 LAG(,2) 可读性差、且 Presto 优化器对嵌套窗口支持弱。更稳的做法是用 ROW_NUMBER() 打标后自连接，但必须控制连接范围。
- 先 CTE 打序：
SELECT user_id, event_type, event_time, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY event_time, event_id) AS rn FROM events WHERE event_type IN ('view','add_to_cart','place_order','pay') - 自连接时加时间约束：
ON a.user_id = b.user_id AND b.rn = a.rn + 1 AND b.event_time ，否则 Presto 易生成笛卡尔积 - 避免
SELECT *进入连接：只选必要字段（user_id, rn, event_type, event_time），减少内存压力 - 四步链路建议拆成两个 CTE：先筛出 valid view→cart，再和 place_order 关联，最后连 pay——比单次四表 JOIN 更可控
Presto 中 windowFunnel() 比手写窗口快多少？什么场景能用？
windowFunnel() 是 Presto/Trino 的专有函数（非标准 SQL），底层用 C++ 实现路径匹配，在百万级以上用户行为数据上比纯 SQL 窗口快 5–8 倍，但有强约束。
- 只能用于
GROUP BY user_id场景，输出是每个用户的最大匹配深度（如 3 表示走到第三步），不返回中间步骤明细 - 时间窗口必须用固定单位：
INTERVAL '1' DAY合法，INTERVAL '30' MINUTE在部分 Trino 版本会报错，得换算成INTERVAL '1800' SECOND - 事件序列必须按字符串字面量写死：
windowFunnel(86400, 'default', event_time, event_type = 'view', event_type = 'add_to_cart', event_type = 'pay')，无法动态传参 - 不支持属性下钻（比如 “同一用户不同商品 ID 的独立漏斗”），遇到这类需求仍得回归
ROW_NUMBER()+CONCAT(user_id, '_', product_id)构造虚拟 ID
最易被忽略的一点：Presto 的窗口函数默认不走索引，PARTITION BY user_id ORDER BY event_time 再快也扛不住全表扫描。上线前务必确认源表（如 Hive 分区表）已按 user_id + event_time 排序存储，否则优化全白费。
