# 计算每月的涨粉情况，总粉丝量就是累加窗口

# 创建临时表，查询必要的用户，年月，涨粉情况——1，-1,0
WITH temp_0 AS
    (
    SELECT author, DATE_FORMAT(start_time, '%Y-%m') the_month, 
        CASE WHEN if_follow = 1 THEN 1
            WHEN if_follow = 0 THEN 0
            ELSE -1 END fo_count
    FROM tb_video_info
    JOIN tb_user_video_log USING(video_id)
    )

# 总的粉丝量是指涨了多少粉，并不是最终得到的粉丝数，而是所有得到过的
# 查询用户，年月，涨粉率，这几个是常规操作
# 下面的是累计粉丝数，一眼就知道要用聚合窗口函数，但是在groupby里面不能用窗口函数，所以就在SUM外面又套了一层SUM，得到的结果并没有变，最后限制年份
# 使用嵌套的 SUM 可能是为了先在 GROUP BY 的级别上聚合数据，然后再使用窗口函数来计算每个作者的累积总和
SELECT author, the_month, ROUND(SUM(fo_count)/COUNT(*), 3) fans_growth_rate, 
SUM(SUM(CASE WHEN fo_count = 1 THEN 1 WHEN fo_count = -1 THEN -1 ELSE 0 END)) OVER(PARTITION BY author ORDER BY the_month) total_fans
FROM temp_0
WHERE LEFT(the_month, 4) = 2021
GROUP BY author, the_month
ORDER BY author, total_fans

原来可以嵌套聚合函数，这样就不与分组语句冲突了

当您在 SQL 查询中使用 SUM 聚合函数，并且同时使用了 GROUP BY 语句时，确实会有特定的规则和限制。在您的查询中，如果只使用一个 SUM 而出现错误，可能是因为 GROUP BY 语句与窗口函数的使用产生了冲突。让我们来探讨这两者之间的关系：

  1. 聚合函数与 GROUP BY：当您使用聚合函数（如 SUM, COUNT, AVG 等）时，这些函数通常是在 GROUP BY 语句的上下文中使用的。GROUP BY 语句用于指定如何将行分组为更小的集合，并且聚合函数会对每个这样的集合进行操作。
  2. 窗口函数：窗口函数（如 SUM(...) OVER (...)）允许您在指定的数据窗口上执行计算，而不会合并行，它们保持原始行的数量。使用窗口函数时，您可以在不同的行上进行聚合操作，同时保留详细的行级数据。
  3. 冲突的原因：如果在 GROUP BY 子句的上下文中直接使用窗口函数，可能会导致逻辑冲突。因为 GROUP BY 试图将数据合并到组级，而窗口函数试图在更细粒度的级别上运行。在 GROUP BY 之后使用窗口函数通常是可以的，但直接将窗口函数应用于 GROUP BY 中的聚合结果可能会导致错误或不可预料的行为。

针对您的查询，如果只使用一个 SUM 而不是嵌套的 SUM(SUM(...)) OVER (...)，您可能需要确保窗口函数的使用与 GROUP BY 子句不冲突。您的原始查询使用嵌套的 SUM 可能是为了先在 GROUP BY 的级别上聚合数据，然后再使用窗口函数来计算每个作者的累积总和。如果您移除其中一个 SUM，您可能就打破了这种逻辑，导致查询无法按照预期执行。