直接用lag(close, 1) over (order by trade_time)可取前一根k线收盘价，但必须确保trade_time为精确到秒/毫秒的时间戳类型并严格排序，避免varchar日期导致错序；首行返回null需用coalesce处理，且高频场景须建(stock_code, trade_time)复合索引优化性能。
LAG() 函数怎么拿到前一根K线的收盘价？
直接用 LAG(close, 1) 就能取上一行的 close 值，但前提是数据必须按时间严格排序。股票数据常有停牌、复牌或非交易日缺失，ORDER BY trade_date 必须用 DATE 类型字段（不能是字符串），否则排序错乱会导致前一日变成上周五甚至更早。
常见错误现象：LAG(close, 1) OVER (ORDER BY trade_date) 返回 NULL 或跳日——大概率是 trade_date 存的是 VARCHAR，比如 '20230101'，排序时 '20230101' DATE： CAST(trade_date AS DATE) 或 TO_DATE(trade_date, 'YYYYMMDD')（依数据库而定）。
计算涨跌幅时为什么结果不准？
用 LAG() 算单日涨跌幅，核心公式是 (close - LAG(close, 1) OVER (...)) / LAG(close, 1) OVER (...)，但两个 LAG() 调用会被分别执行，若窗口定义不一致（比如一个漏写 PARTITION BY stock_code），就会跨股票混算。A股和港股代码不同，必须按标的隔离。
实操建议：
- 所有涉及多只股票的分析，
OVER子句必须带PARTITION BY stock_code - 避免重复写
LAG(close, 1)两次——用子查询或 CTE 提前算出prev_close，再统一计算，既清晰又防错 - 除零要处理：
NULLIF(LAG(close, 1) OVER (...), 0)包裹分母，避免报错
如何识别连续3根阳线？
连续阳线本质是判断当前及前两根K线是否都满足 close > open，且时间连续。仅靠 LAG() 只能取值，不能“跨行断言”，必须组合布尔值与窗口聚合。
关键点：
- 先用
LAG()拿到前两根的open和close，生成三列布尔标志：is_bull、is_bull_prev1、is_bull_prev2 - 再用
SUM()窗口函数统计最近3行（含当前）的is_bull和：SUM(CASE WHEN is_bull THEN 1 ELSE 0 END) OVER (ORDER BY trade_date ROWS BETWEEN 2 PRECEDING AND CURRENT ROW) - 结果等于3即为连续3阳——注意
ROWS BETWEEN ...是硬性行偏移，不依赖日期是否连续；若需真正“交易日连续”，得先生成完整日历表 LEFT JOIN 补空，再用RANGE或业务逻辑过滤
LAG() 在高频Tick数据里性能崩了怎么办？
分钟级或Tick级数据量大时，LAG() 本身不慢，慢在排序和窗口框架扫描。尤其当 PARTITION BY stock_code ORDER BY ts 中 ts 有大量重复（如毫秒级时间戳+同秒多笔成交），排序不稳定会引发 LAG() 结果抖动。
优化方向：
- 确保
ts字段有复合索引：(stock_code, ts)，且ts类型为TIMESTAMP而非字符串 - 避免在
SELECT里嵌套多层LAG()（如LAG(LAG(close))），改用 CTE 展开中间步骤 - PostgreSQL 可加
ROWS UNBOUNDED PRECEDING显式限定范围；MySQL 8.0+ 需注意WINDOW定义复用，减少重复计算
真正容易被忽略的是：K线图波动趋势分析从来不是单靠 LAG() 就能闭环的——它只解决“取前值”，而趋势需要结合移动平均、高低点识别、成交量验证。把 LAG() 当成扳手，别当成整套工具箱。
