LAG和LEAD在K线序列中易出错，因SQL不保证天然行序，必须显式用ORDER BY timestamp ASC定义逻辑顺序；漏写排序、未处理同一时间戳重复、未设ROWS框架或误用PARTITION BY均会导致结果静默错误。
为什么 LAG 和 LEAD 在K线序列里容易出错
金融K线数据天然有序（按时间戳升序），但SQL默认不保证行序，必须显式用 ORDER BY 配合窗口定义，否则 LAG(close, 1) 可能取到未来某根K线的收盘价。常见错误是只写 OVER () 而漏掉排序子句。
实操建议：
- 所有涉及时序偏移的窗口函数，
OVER子句必须包含ORDER BY timestamp ASC（或datetime字段） - 若存在同一时间戳多条记录（如高频撮合），需追加唯一排序字段，例如
ORDER BY timestamp ASC, trade_id ASC -
LAG默认返回NULL，在计算涨跌幅时要主动处理，比如COALESCE(LAG(close) OVER (...), open)补首根K线的前收
用 MAX/MIN 窗口函数做滚动高低点统计
计算最近 N 根K线的最高价、最低价，不能用聚合查询（会丢失原始行），必须用窗口函数。关键在于指定 ROWS BETWEEN 框架，而非默认的 RANGE（后者对时间戳可能误匹配）。
实操建议：
- 滚动 5 根K线高点：
MAX(high) OVER (ORDER BY timestamp ASC ROWS BETWEEN 4 PRECEDING AND CURRENT ROW) - 避免写成
RANGE BETWEEN INTERVAL '4 hours' PRECEDING AND CURRENT ROW——K线非等间隔，时间范围会导致漏算或重复 - 若需“从当前K线往前含自身共N根”，行数应设为
N-1 PRECEDING，不是N PRECEDING
FIRST_VALUE 和 LAST_VALUE 在开收价统计中的陷阱
初看 FIRST_VALUE(open) 像是取周期开盘价，但默认框架是 UNBOUNDED PRECEDING AND CURRENT ROW，导致每行都返回当前K线的 open。必须显式重定义窗口范围才能拿到真实周期起点值。
实操建议：
- 计算当前K线所在日的开盘价：先用
DATE(timestamp)分组，再FIRST_VALUE(open) OVER (PARTITION BY DATE(timestamp) ORDER BY timestamp ASC) - 若要滚动 10 根K线的“起始开”和“结束收”，用
FIRST_VALUE(open) OVER w和LAST_VALUE(close) OVER w，并定义w AS (ORDER BY timestamp ASC ROWS BETWEEN 9 PRECEDING AND CURRENT ROW) -
LAST_VALUE默认行为是截断到CURRENT ROW，务必补上ROWS BETWEEN ... AND UNBOUNDED FOLLOWING或改用FRAME显式声明，否则结果不可靠
性能敏感点：为什么 PARTITION BY 比 ORDER BY 更耗资源
在千万级K线表上，PARTITION BY symbol ORDER BY timestamp 比单纯 ORDER BY timestamp 多出哈希分发与局部排序开销。尤其当股票/合约数量多、每只标的K线稀疏时，分区键选择直接影响执行计划是否走索引。
实操建议：
- 优先在
(symbol, timestamp)上建复合索引，让窗口函数能利用索引顺序，避免全局排序 - 避免在
PARTITION BY中使用表达式，如PARTITION BY SUBSTRING(symbol, 1, 3)，会导致无法命中索引 - 若只需全市场统一滚动统计（如全市场平均振幅），直接去掉
PARTITION BY，仅靠ORDER BY timestamp+ROWS框架，性能通常更好
窗口函数本身不难，难的是把K线的时间语义、业务周期和SQL执行模型对齐。一个没写对的 ROWS 或漏掉的 PARTITION BY，会让结果在回测中静默漂移——这种错误很难被肉眼发现。
