时间序列趋势分析需先按组和时间排序，再用LAG()/LEAD()计算组内相邻差值；必须PARTITION BY分组，补全缺失时间点，用窗口聚合识别连续变化，并优化大分组性能。
用 LAG() 或 LEAD() 计算组内相邻时间点的差值
分组趋势分析本质是看「同一组里，不同时间点的指标怎么变」。直接 GROUP BY 会丢失时序顺序，必须先按组和时间排序，再用窗口函数抓前后行。MySQL 8.0+、PostgreSQL、SQL Server 都支持 LAG()，但 SQLite 默认不支持（需编译启用）。
常见错误是忘了 PARTITION BY —— 比如分析每个用户每月订单额变化，却只写 ORDER BY order_month，结果所有用户数据被混在一起算差值。
- 必须显式写
PARTITION BY user_id ORDER BY order_month -
LAG(total_amount, 1)表示取前 1 行的total_amount，返回NULL（不是 0），做减法前建议用COALESCE()处理 - 如果时间字段有空缺（比如某用户 3 月没订单），
LAG()会跳到 2 月，而非“逻辑上”的上个月——这时需要先补全时间序列（见下一条）
SELECT user_id, order_month, total_amount, total_amount - COALESCE(LAG(total_amount) OVER (PARTITION BY user_id ORDER BY order_month), 0) AS month_over_month_diff FROM monthly_user_summary;
补全缺失时间点：用 GENERATE_SERIES() 或自关联构造时间维度
真实业务中，用户/设备/商品经常有“断更”——某个月没数据，但趋势分析需要知道“这个月是 0”，否则环比计算就断层。PostgreSQL 10+ 有 GENERATE_SERIES()，MySQL 和 SQL Server 得靠递归 CTE 或日历表。
容易踩的坑是补全后没和原表 LEFT JOIN，而是 INNER JOIN，结果又把空月份过滤掉了；或者补全时没限定组范围，导致 A 用户的时间序列里混入了 B 用户的月份。
- PostgreSQL 示例：先用
SELECT DISTINCT user_id FROM t得到所有组，再和GENERATE_SERIES(min_month, max_month, '1 month')叉乘 - MySQL 8.0：用递归 CTE 构造月份，注意
WITH RECURSIVE的终止条件别写错，否则无限循环 - 补完后务必用
COALESCE(t.total_amount, 0)把空值转成 0，再进窗口函数
识别趋势方向：用 CASE WHEN + 窗口聚合判断连续增长/下降
单纯看单月差值不够——用户连续 3 个月上涨，比某月暴涨更有价值。这时候不能只依赖 LAG()，得统计「当前行往前 N 行中，有多少个是正向变化」。
典型错误是试图在 WHERE 里直接用窗口函数结果（如 WHERE count_up >= 3），会报错，因为窗口函数不能出现在 WHERE 阶段；必须用子查询或 CTE 包一层。
- 用
SUM(CASE WHEN diff > 0 THEN 1 ELSE 0 END) OVER (PARTITION BY user_id ORDER BY order_month ROWS BETWEEN 2 PRECEDING AND CURRENT ROW)统计最近 3 期上涨次数 - 注意
ROWS BETWEEN ... AND ...是物理行偏移，不是时间偏移；若中间有空月，可能统计不准——所以补全时间点这步不能省 - SQL Server 的
ROWS和RANGE行为不同，RANGE会合并相同排序值的行，慎用
性能陷阱：窗口函数 + 大分组 + 高频时间粒度
当分组数超 10 万（比如 10 万个 IoT 设备）、时间粒度是小时级时，PARTITION BY device_id ORDER BY ts 会触发大量小排序，磁盘临时表暴增，查询从秒级变分钟级。
这不是语法问题，是执行计划层面的瓶颈。优化核心是减少参与窗口计算的行数，而不是调参数。
- 先用
WHERE ts >= '2024-01-01'严格过滤时间范围，避免扫描全量历史 - 对高基数分组字段（如
device_id）建联合索引：(device_id, ts)，让排序能走索引扫描 - PostgreSQL 中可考虑分区表按
device_id哈希分区，但要注意查询必须带等值条件才能裁剪分区 - 如果只要最近 N 期趋势，用
ROWS BETWEEN N-1 PRECEDING AND CURRENT ROW比UNBOUNDED PRECEDING快得多
时间序列趋势分析最难的从来不是写对 SQL，而是想清楚「你要的趋势，到底依赖哪几个时间点、允许多大误差、能不能接受插值」——这些决定了该不该补全、该不该用 LAG 还是拟合斜率、甚至该不该离开 SQL 去用 Python 做 rolling 计算。
