子查询实现滚动平均结果全为NULL，是因为未限定“当前行及之前”的范围，导致查空集合；必须用相关子查询并正确设置时间/序号边界条件。
子查询写滚动平均时，为什么结果全是 NULL？
常见现象：AVG() 子查询返回 NULL，尤其在窗口起始几行——不是函数错了，是子查询没限定“当前行及之前”，而是查了空集合。
关键点：滚动统计必须明确范围边界。用子查询模拟滚动窗口，本质是「对每一行，查它和前面 N 行的聚合」，得靠外部行的主键/时间戳做关联约束。
- 必须用相关子查询（correlated subquery），即子查询里引用外部表的字段，比如
t1.order_date - 子查询的
WHERE条件要写成t2.order_date t1.order_date - INTERVAL '7 days'（PostgreSQL）或等效逻辑 - MySQL 5.7 或更早不支持
INTERVAL，得用DATE_SUB(t1.order_date, INTERVAL 7 DAY)；SQLite 用date(t1.order_date, '-7 days') - 如果排序字段有重复值（比如多笔同秒订单），单纯靠时间可能漏行或多算——此时必须加唯一序号（如自增
id）辅助断点
用子查询替代 OVER (ORDER BY ... ROWS BETWEEN ...) 的实际代价
能跑通不等于该用。子查询滚动统计在数据量稍大时性能会断崖下跌。
原因：每行都触发一次独立子查询，复杂度从 O(n) 变成 O(n²)。10 万行可能查 100 亿次记录扫描（尤其没索引时）。
- 确保子查询中用于关联和过滤的字段（如
order_date、id）已建复合索引，例如CREATE INDEX idx_date_id ON sales(order_date, id) - PostgreSQL/SQL Server 支持
LATERAL（或APPLY），可让子查询“感知”外部行并复用执行计划，比普通相关子查询快得多 - 如果只是求 7 日滚动总和，且数据按天分区，可先按日聚合再用子查询，减少原始行数
子查询实现滚动计数时，COUNT(*) 和 COUNT(column) 差在哪？
区别直接决定业务逻辑是否准确。滚动统计里，空值（NULL）是否计入，由你选的函数决定。
典型场景：统计过去 30 天内「有效下单用户数」，但 user_id 字段偶尔为 NULL（比如游客下单未留 ID）。
-
COUNT(*)统计所有匹配行，不管user_id是不是NULL -
COUNT(user_id)只统计user_id IS NOT NULL的行——这才是真实「有效用户数」 - 如果误用
COUNT(*)，滚动结果会虚高；反过来，若字段本不该为空却出现NULL，说明上游数据有问题，得往前追清洗逻辑
MySQL 8.0 以下版本没窗口函数，子查询真能完全替代吗？
不能。子查询能凑出简单滚动聚合，但遇到「跳过空值重排序号」「动态分组内滚动」「带条件的累计占比」就力不从心。
比如想算「每个品类下，销量滚动前 10% 的商品累计占比」，子查询很难优雅表达嵌套层级和比例计算。
- 优先升级到 MySQL 8.0+，原生
OVER性能好、语义清、易调试 - 实在不能升级，可用临时表 + 自连接预计算：先按时间排序生成序号，再用
JOIN关联前后行，比纯子查询可控 - 避免在子查询里套子查询（三层以上），MySQL 5.7 解析器容易崩溃或生成错误执行计划
滚动统计真正的难点从来不在语法，而在时间边界定义是否和业务口径一致——比如「过去 7 天」是指自然日、工作日，还是最近 7 个有数据的日期？这个逻辑一旦写死在子查询里，后续改起来比换数据库还麻烦。
