count()是聚合函数，压缩行数；count() over()是窗口函数，保持原始行数，在指定窗口内逐行累计计数，需partition by分组和order by排序才能实现动态累计。
什么是 COUNT OVER 与普通 COUNT 的关键区别
COUNT 单独用是聚合函数，会压缩行数；而 COUNT() OVER 是窗口函数，不改变原始行数，只在指定窗口内计算计数。要实现“各类别的动态累计频次”，核心不是单纯计数，而是按类别分组 + 按时间/顺序递增累计 —— 这必须靠 OVER 子句里的 PARTITION BY 和 ORDER BY 联合控制。
常见错误现象：COUNT(*) OVER (PARTITION BY category) 只给每类总数，不是累计；漏掉 ORDER BY 就无法体现“动态”和“逐行累加”。
实操建议：
-
ORDER BY必须存在，且字段需有明确业务序（如created_at、id），否则累计无意义 - 若想按插入顺序累计但无时间戳，可用
ROW_NUMBER() OVER (ORDER BY ctid)（PostgreSQL）或ORDER BY (SELECT NULL)（不推荐，行为不可靠） - MySQL 8.0+、PostgreSQL、SQL Server、Oracle 都支持；SQLite 3.25+ 支持，但旧版不支持窗口函数
如何写一个带类别分组的累计频次语句
典型场景：日志表 events 有 category 和 created_at，想看每个类别下，按时间顺序逐条出现时的“这是该类第几次出现”。
正确写法：
SELECT
category,
created_at,
COUNT(*) OVER (
PARTITION BY category
ORDER BY created_at, id
ROWS UNBOUNDED PRECEDING
) AS cum_count
FROM events;
说明：
-
PARTITION BY category确保各组独立计数 -
ORDER BY created_at, id解决时间相同时的排序歧义（避免相同created_at导致累计值跳变或重复） -
ROWS UNBOUNDED PRECEDING是默认行为，可省略，但显式写出更清晰——表示从分区开头累加到当前行 - 别名
cum_count是累计值，首行即为 1，逐行 +1（同类别内）
为什么不能用 SUM(1) OVER 替代 COUNT(*) OVER
看起来 SUM(1) OVER (...) 和 COUNT(*) OVER (...) 结果一样，但语义和健壮性不同。
关键差异：
-
COUNT(*)明确统计“行数”，无视 NULL；SUM(1)是数值求和，虽结果一致，但若误写成SUM(some_col)且该列含 NULL，就会少计 - 某些数据库（如早期 SQL Server）对
SUM()窗口函数的优化路径不如COUNT()稳定 - 当需要累计“非空值个数”时，应写
COUNT(col_name) OVER (...)，而非SUM(CASE WHEN col_name IS NOT NULL THEN 1 ELSE 0 END)
容易被忽略的边界问题
实际跑出来发现累计值“断层”或“重置异常”，大概率是以下原因：
- ORDER BY 字段含 NULL：NULL 默认排最前（PostgreSQL、SQL Server）或最后（MySQL），导致同一类别的第一条记录不是最早时间，累计起点错位。建议用
ORDER BY created_at ASC NULLS LAST（PostgreSQL）或COALESCE(created_at, '1970-01-01')兜底 - 时间精度不足：多个事件在同一秒级时间戳，又没加二级排序（如
id），数据库可能任意排序，导致累计值每次执行不一致 - 分区键值本身有隐藏空格或大小写差异：比如
'A '和'A'被视为不同类别，检查是否需用TRIM(UPPER(category))统一后再PARTITION BY
ORDER BY 的确定性、NULL 处理、以及分区键的洁净度，比函数写法本身更容易决定结果是否可信。
