窗口函数通过partition by user_id分区、order by行为时间或金额排序，结合rank()/row_number()生成序号，再用case when划分行为标签；lag/lead需严格配合分区与时间排序构建用户行为路径；累计统计须注意distinct限制和rows/range帧选择，且执行时机在group by之后、order by之前。
窗口函数怎么给用户打行为标签
直接用 RANK() 或 ROW_NUMBER() 按用户行为频次/金额排序，再结合 CASE WHEN 划分层级，比写多层子查询或应用层计算快得多。关键不是“算什么”，而是“在哪算”——必须在用户粒度上分区，否则标签会跨人污染。
-
PARTITION BY user_id是底线，漏掉就等于把所有人的浏览、加购、下单混在一起排 - 排序字段选
order_date还是amount取决于目标：前者适合识别活跃周期（如最近3次下单间隔），后者适合识别高价值行为 - 避免用
ORDER BY COUNT(*)这类聚合表达式直接排序——窗口函数不接受在OVER()里嵌套聚合，得先用子查询或 CTE 聚合好再开窗
怎么用 LAG/LEAD 提取用户行为路径
电商推荐最怕“静态画像”，而 LAG() 和 LEAD() 能把用户行为串成时序链，比如“看过A商品后是否加购B”“下单前是否搜索过竞品词”。这不是简单查表，是构造行为状态转移。
- 必须配合
ORDER BY order_date，否则前后行关系无意义；时间字段若为STRING类型（如'2023-10-05'），要先转成DATE再排序，不然字符串比较会出错 -
LAG(product_id, 1)只能取上一行，如果想看“上一次购买的类目”，得先按user_id分区、再按时间排序，否则会拉到别人的数据 - 注意 NULL 处理：首次行为没有“上一次”，
LAG()返回 NULL，别直接参与 WHERE 条件，建议用COALESCE(LAG(...), 'first_time')
累计行为统计为什么不能只靠 SUM() OVER
SUM(amount) OVER (PARTITION BY user_id ORDER BY order_date) 看似能算用户累计消费，但电商场景下常需“去重累计”或“带权重累计”，原生 SUM() 无法处理。
- 比如计算“累计购买不同类目数”，不能直接
SUM(DISTINCT category)——窗口函数不支持DISTINCT修饰，得用COUNT(DISTINCT category) OVER (...)，但 PostgreSQL 14+ 才支持，MySQL 8.0 不支持 - 若需“近90天累计”，不能只靠
ORDER BY，必须加ROWS BETWEEN 89 PRECEDING AND CURRENT ROW或用RANGE BETWEEN INTERVAL '89 days' PRECEDING AND CURRENT ROW（PostgreSQL 支持，MySQL 不支持 RANGE + INTERVAL） - 更隐蔽的坑：当用户某天有多笔订单，
ROWS BETWEEN ...按行数框定会漏数据；用RANGE按时间框定才可靠，但代价是性能下降
窗口函数和 pgvector 向量检索怎么协同
纯 SQL 窗口函数解决不了“相似用户推荐”，但它能预筛出高潜力人群，再交由 pgvector 做向量召回——这是实际生产中最常见的混合架构。
- 先用窗口函数生成标签表：比如
WITH top_users AS (SELECT user_id FROM orders GROUP BY user_id HAVING COUNT(*) > 5) SELECT * FROM top_users，再把这个结果集作为pgvector的输入范围 - 别在
WHERE条件里直接写embedding (SELECT ...)子查询调用窗口逻辑——子查询不能含窗口函数，会报错ERROR: window functions are not allowed in WHERE - 真正落地时，窗口计算通常放在 ETL 阶段产出宽表（如
user_profile_v1），而pgvector只负责对这张宽表做相似检索，分工明确才能稳住延迟
真实项目里最容易被忽略的，是窗口函数的执行时机——它在 GROUP BY 之后、ORDER BY 之前计算。这意味着你不能指望它修正已聚合的结果，也不能用它替代 JOIN；它只负责在最终输出行上“贴”一个动态计算值。
