sql中计算5日均线必须用avg()窗口函数并显式指定order by trade_date和rows between 4 preceding and current row，否则返回全量均值；sqlite不支持rows，需改用自连接或预补日期；null值会被自动忽略，可能掩盖数据问题，建议检查并预处理；trade_date字段须建索引以保障性能。

SQL里用AVG()算5日均线必须加ORDER BY和ROWS BETWEEN

不指定窗口排序和范围，AVG()会返回全量均值，不是你要的“最近5个交易日”的移动平均。核心是把AVG()变成窗口函数，且必须显式定义时间顺序和行数边界。

• ORDER BY trade_date不能省——股票数据按日期排序才有“前5日”意义，否则窗口方向不确定
• ROWS BETWEEN 4 PRECEDING AND CURRENT ROW才是5日：当前行 + 往前4行 = 5行。写成5 PRECEDING就错了，那会包含6行
• 如果日期有缺失（比如节假日休市），用trade_date排序仍能保证“交易日数量”准确；但若想按自然日回溯，就得先生成连续日期再左连接补空，那是另一层问题

PostgreSQL/MySQL 8.0+/SQL Server 都支持，但SQLite不支持ROWS BETWEEN

SQLite的AVG()窗口函数只支持RANGE（基于值范围），不支持ROWS（基于行数），所以无法严格按“5个交易日”计算。遇到SQLite必须换思路：

• 用自连接或子查询手动关联最近5条记录，性能差但可行
• 提前在应用层或ETL中补全日期、填充NULL值，再用RANGE BETWEEN INTERVAL '4 days' PRECEDING AND CURRENT ROW（仅PostgreSQL支持）
• 直接导出到支持ROWS的引擎里算，别硬扛

遇到NULL收盘价时AVG()自动跳过，但可能掩盖数据质量问题

窗口AVG()默认忽略NULL，比如某只股票第3日close_price为NULL，那第5日的均线实际只算4个有效值。这看起来“合理”，但容易掩盖上游数据异常：

• 检查原始数据中close_price IS NULL的比例，高频出现说明数据源有问题
• 若需强制5日参与（比如用前值填充），得先用COALESCE(close_price, LAG(close_price) OVER (ORDER BY trade_date))预处理
• 注意AVG()结果类型：整数列可能被截断，建议显式转DECIMAL(10,2)或FLOAT

性能关键点：trade_date字段必须建索引，且避免在窗口函数里套复杂表达式

数据库优化器对窗口函数的执行计划依赖排序字段的索引。没索引时，每行都要重新扫描前5行，O(n²)复杂度。

• 确保CREATE INDEX idx_stock_date ON stock_prices (symbol, trade_date);——复合索引兼顾多股票场景
• 别写AVG(COALESCE(close_price * 1.0, 0))这种带运算的表达式，先算好列再进窗口
• 如果只查某只股票，WHERE symbol = '600519'必须放在窗口计算之前，否则全表扫完才过滤

窗口函数的“5日”是硬性行数约束，不是软性时间逻辑。哪怕某天数据延迟入库，只要它排在第5位，就会被纳入——这点和K线软件里的实现一致，但也意味着你要对数据落库顺序有掌控力。