窗口函数按时间排序需明确指定高精度时间字段并配合唯一字段二级排序，否则LAG/LEAD结果不可靠；计算同比/环比时NULL多因分区或排序错误、时间不连续；ROWS适合按行数取值，RANGE适合按时间范围取值；优化性能需建联合索引、提前过滤、避免多层嵌套。
窗口函数怎么按时间排序才不会乱序？
时间序列数据最怕排序错，ORDER BY 必须明确指定时间字段，且该字段不能有重复值（或需配合 ROW_NUMBER() 等辅助去重）。如果用 timestamp 字段但精度不足（比如只到秒），多个事件在同一秒发生，LAG() 或 LEAD() 的结果就不可靠。
- 优先用带毫秒/微秒的
created_at或event_time字段，而不是date类型 - 如果时间字段有重复，加一个唯一字段（如
id）做二级排序：ORDER BY event_time, id - 切忌在窗口定义里漏写
ORDER BY：没有它，ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW这类范围就失去意义
计算同比/环比时为什么结果总是 NULL？
LAG() 和 LEAD() 在边界位置（比如第一条或最后一条记录）默认返回 NULL，这是正常行为，不是 bug。但如果你看到大量 NULL，大概率是分区或排序没对。
- 先确认是否用了
PARTITION BY：比如按设备 ID 分区后，每个设备各自计算环比，跨设备不连贯 - 检查时间是否连续：窗口函数不会自动补缺失日期，2023-01-01 和 2023-01-03 之间没有 02 日，
LAG(value, 1)就会跳到 01 日的值，而非“上一天” - 若需严格按日历日期对齐，得先用
GENERATE_SERIES（PostgreSQL）或递归 CTE 补全日期，再 LEFT JOIN 原表
用 ROWS BETWEEN 还是 RANGE BETWEEN？
ROWS 按物理行数算，RANGE 按排序键值范围算。时间序列里，多数情况该用 ROWS，除非你真要“过去 7 天内所有记录”的语义。
-
ROWS BETWEEN 6 PRECEDING AND CURRENT ROW：取当前行和它前面 6 行（共 7 行），不管这些行的时间跨度是 1 小时还是 3 天 -
RANGE BETWEEN INTERVAL '7 days' PRECEDING AND CURRENT ROW（PostgreSQL / BigQuery 支持）：取时间值在 [当前时间 − 7天, 当前时间] 内的所有行 - MySQL 8.0+ 不支持
INTERVAL在RANGE中，只能退化为ROWS+ 预处理时间分组 - 性能上，
ROWS更快；RANGE在时间稀疏时更准，但可能扫描更多行
如何避免窗口函数拖慢大表查询？
窗口函数本身不索引友好，尤其带 PARTITION BY 和复杂 ORDER BY 时，容易触发磁盘排序。
- 确保
PARTITION BY字段（如user_id）和ORDER BY字段（如event_time）上有联合索引，例如：CREATE INDEX idx_user_time ON events(user_id, event_time) - 避免在子查询里套多层窗口函数；能提前过滤就先
WHERE，比如只查最近 30 天数据，别让窗口函数扫全表 - 在 PostgreSQL 中，
EXPLAIN ANALYZE里注意是否出现WindowAgg (disk)—— 这说明内存不够，得调大work_mem - Hive/Spark SQL 中，
PARTITION BY的列 cardinality 不能太高（如每行都不同），否则 shuffle 开销爆炸
时间序列窗口计算真正难的不是语法，而是搞清“你要对谁比、按什么对齐、缺数据怎么算”。写完记得用小样本手工验算两行，比盯着执行计划有用得多。
