17370845950

SUM() OVER 本身不溢出，溢出源于INT类型隐式计算导致中间结果超限；解决方法是提前将输入列转为BIGINT等更大类型，并显式指定ORDER BY确保累计顺序。

为什么 SUM() OVER 会“溢出”？其实是数据类型隐式转换问题 SUM() OVER 本身不会溢出，但当你对 INT 列（比如订单金额为 INT）做累计求和时，中间结果仍按 INT 计算，一旦超过 2147483647 就会截断或报错（取决于数据库）。PostgreSQL 会报 integer out of range，SQL Server 可能静默溢出，MySQL 5.7+ 默认也报错。 关键不是窗口语法，而是**输入表达式的类型决定了聚合的计算类型**。

解决方法很简单：提前把参与累计的列转成更大容量类型：

• PostgreSQL / SQL Server / MySQL 8.0+：用 CAST(amount AS BIGINT) 或 amount::BIGINT
• 如果原始列已是 BIGINT，但你还加了其他 INT 常量（如 + 1），也要一并转： CAST(amount AS BIGINT) + CAST(1 AS BIGINT)
• 避免写 SUM(CAST(amount AS BIGINT)) OVER (ORDER BY id) —— 这里 CAST 放在 SUM 内部是正确且必要的；放在外面（如 CAST(SUM(amount) AS BIGINT)）就晚了，溢出已发生

ORDER BY 必须明确，否则累计逻辑不可靠 窗口累计求和依赖行序。不写 ORDER BY 子句时，SUM() OVER () 是全表总和（非累计），且不同数据库行为不一致：PostgreSQL 允许但结果无序，SQL Server 要求显式 ORDER BY 或 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW。

实操建议：

• 永远显式写 ORDER BY，例如：SUM(CAST(amount AS BIGINT)) OVER (ORDER BY created_at, id)
• 如果业务上存在时间相同的数据，必须加入唯一性列（如 id）避免排序不确定性
• 不要依赖主键隐式顺序，有些数据库优化器可能重排

性能敏感场景：慎用 RANGE，优先用 ROWS SUM() OVER (ORDER BY x RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) 看似自然，但 RANGE 在值重复时会合并多行（比如多个相同 created_at），导致累计值“跳变”，且多数数据库无法高效索引 RANGE 窗口。

更稳更快的做法：

• 用 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW（这是默认行为，可省略）
• 确保 ORDER BY 列有索引，尤其是复合排序字段（如 (created_at, id)）
• 在 PostgreSQL 中，若数据量极大，考虑用 LATERAL JOIN + 子查询替代复杂窗口，但仅当 EXPLAIN ANALYZE 确认窗口变慢时才动手

MySQL 5.7 和 8.0 的关键差异点 MySQL 5.7 不支持窗口函数，强行写会报错 ERROR 1064。MySQL 8.0+ 才支持，但默认开启严格模式（sql_mode 含 STRICT_TRANS_TABLES），此时 INT 溢出会直接中断查询。

检查与修复步骤：

• 确认版本：SELECT VERSION();
• 查当前模式：SELECT @@sql_mode;

  

  ，若含 STRICT_*，溢出即报错；若没有，则可能静默截断为 2147483647 或 -2147483648
• 最稳妥写法：SUM(CAST(amount AS DECIMAL(20,2))) OVER (ORDER BY id)，DECIMAL 避免整数溢出，也适配金额类业务语义

跨行累计看着简单，真正上线后出问题的，八成卡在类型没升上去、排序没定死、或者压根没意识到 MySQL 5.7 根本不认 OVER。