如何利用SQL子查询实现滚动窗口统计
在数据分析中，我们常常需要计算滚动平均值、累计总和这类指标。当数据库版本较老，不支持窗口函数时，子查询就成了“救火队员”。但这条路，走起来可没那么平坦。
子查询写滚动平均时，为什么结果全是 NULL？
很多朋友都踩过这个坑：写好的A VG()子查询，跑出来的结果全是NULL，尤其是数据表开头那几行。这通常不是聚合函数出了问题，而是子查询的“视野”没对准。
问题的核心在于范围界定。用子查询模拟滚动窗口，本质是告诉数据库：“对于每一行，请帮我计算它以及它前面若干行的聚合值。”如果子查询没有正确关联到外部行，并限定“之前”的范围，它就会去查询一个空集合，返回NULL也就成了必然。
关键在于写出一个相关子查询，并精确设定时间或序号边界：
- 必须使用相关子查询：子查询内部需要引用外部表的主键或时间戳，例如
t1.order_date，这样才能建立行与行之间的关联。 - 精确书写WHERE条件：条件应明确表达“在某个时间点之前”的逻辑。例如在PostgreSQL中，可以写成
t2.order_date BETWEEN t1.order_date - INTERVAL '7 days' AND t1.order_date。 - 注意数据库方言：MySQL 5.7等旧版本可能不支持直接的
INTERVAL运算，需要用DATE_SUB(t1.order_date, INTERVAL 7 DAY)；SQLite则使用date(t1.order_date, '-7 days')这样的函数。 - 处理重复值：如果排序字段（如订单时间）存在重复，仅靠时间条件可能导致统计偏差。这时，引入一个唯一序号（如自增
id）作为辅助断点，是确保精确性的常见做法。
子查询实现滚动平均结果全为NULL，是因为未限定“当前行及之前”的范围，导致查空集合；必须用相关子查询并正确设置时间/序号边界条件。
用子查询替代 OVER (ORDER BY ... ROWS BETWEEN ...) 的实际代价
语法能跑通，不代表就应该这么用。用子查询来实现滚动统计，在数据量稍大的场景下，性能代价可能超乎想象。
原因很简单：对于结果集中的每一行，数据库都要独立执行一次子查询。这导致时间复杂度从窗口函数的O(n)陡增至O(n²)。想象一下，处理10万行数据，可能意味着背后进行了上百亿次的记录扫描——尤其是在关联字段缺乏有效索引的情况下。
如果不得不走这条路，以下几点能帮你“止血”：
- 索引是生命线：务必为子查询中用于关联和过滤的字段建立复合索引。例如，
CREATE INDEX idx_date_id ON sales(order_date, id)。 - 利用高级特性：像PostgreSQL的
LATERAL或SQL Server的APPLY，允许子查询更高效地“感知”外部行并复用执行计划，性能通常优于普通的相关子查询。 - 先聚合，后计算：如果业务是计算“7日滚动总和”，且数据可按天汇总，不妨先进行按日聚合，减少原始行数，再应用子查询逻辑，能显著降低计算负担。
子查询实现滚动计数时，COUNT(*) 和 COUNT(column) 差在哪？
一字之差，结果可能天壤之别。在滚动统计中，选择哪个函数，直接决定了空值（NULL）是否被计入，这关乎业务逻辑的准确性。
来看一个典型场景：统计过去30天内的“有效下单用户数”。假设user_id字段偶尔为NULL（例如游客下单未登录）。
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等版本中，复杂的嵌套查询容易导致解析器生成低效甚至错误的执行计划。
说到底，滚动统计真正的挑战，往往不在于SQL语法本身，而在于时间边界的业务定义是否清晰。所谓的“过去7天”，究竟是指自然日、工作日，还是最近7个有数据记录的日期？这个业务口径一旦被写死在复杂的子查询里，未来想要修改，其难度可能比迁移数据库还要大。在动笔之前，先把这个问题搞清楚，能省去后续无数的麻烦。
