SQL Server窗口函数本身不触发溢出，但窗口聚合因隐式类型提升失效易致静默溢出；须显式CAST输入列、禁用ANSI_WARNINGS OFF、在OVER子句直接转换而非SELECT层。
SQL Server 执行窗口函数本身不会直接触发整数或浮点溢出，但窗口聚合（如 SUM、AVG、COUNT）在累积计算过程中极易因数据规模或类型不匹配导致隐式转换溢出——尤其当输入列是 TINYINT、SMALLINT 或未显式指定精度的 DECIMAL 时。
窗口聚合中隐式类型提升失效的典型场景
SQL Server 在窗口函数中对聚合结果的类型推导，有时会沿用输入列原始类型，而非自动升格。例如：
-
SUM(smallint_col) OVER (PARTITION BY id)返回仍是smallint，若分区和超过 32767，就静默截断为负值（如 32768 → -32768），不报错 -
AVG(numeric(9,2)) OVER ()可能退化为numeric(9,2)而非更宽的numeric(13,4)，小数位不足引发四舍五入失真 - 用
ROW_NUMBER() OVER (...) % 1000做分桶时，若行数超 2147483647（INT上限），ROW_NUMBER()自动转为BIGINT，但取模操作若右侧是INT字面量，仍可能触发隐式转换冲突
如何验证当前窗口聚合是否已发生静默溢出
不能只看执行是否成功；要主动校验中间结果范围：
- 对疑似字段加
CHECKSUM_AGG和COUNT(*)对比：若CHECKSUM_AGG异常稳定（如总为 0）、而COUNT正常增长，大概率存在重复截断 - 用
TRY_CAST强制升格后重算：TRY_CAST(SUM(CAST(col AS BIGINT)) OVER (PARTITION BY x) AS DECIMAL(18,2))，再与原结果比对差异 - 在查询末尾加
HAVING MAX(col) > POWER(2, 15) - 1（针对SMALLINT）等条件，快速定位高风险分区
缓冲区配置不是根本解法，但 work_mem 类似机制需关注
SQL Server 没有 work_mem 这类参数，但它依赖 max server memory 和查询内存授予（query memory grant）。窗口函数若涉及大分区排序或哈希，会申请大量内存；一旦不足，就会 spill 到 tempdb，间接放大溢出风险（例如中间结果写磁盘时被截断）：
- 查当前查询内存授予是否过低：
SELECT granted_memory_kb, used_memory_kb FROM sys.dm_exec_query_memory_grants - 避免让窗口函数处理全表未过滤数据——
WHERE必须在窗口前完成，否则内存授予按原始行数估算，浪费且易 spill - 对高频
PARTITION BY字段建索引（哪怕单列），可使优化器选择 merge join 路径，大幅降低内存需求，从而减少因 spill 导致的中间值精度丢失
真正可控的防御手段只有三件事
别寄希望于调大服务器内存或改配置项来“扛住”溢出——它发生在计算逻辑层，不是资源层：
- 所有参与窗口聚合的数值列，必须显式
CAST到足够宽的类型：SUM(CAST(amount AS DECIMAL(18,2))) OVER (...) - 禁用
ARITHABORT OFF和ANSI_WARNINGS OFF（它们会让溢出变成静默截断） - 在 ETL 或视图定义中，把高危窗口聚合封装为带
TRY_*函数的计算列，让失败暴露在插入/查询时刻，而非藏在报表数字里
最易被忽略的一点：即使你写了 CAST(x AS BIGINT)，如果上游表达式（比如一个标量 UDF 或计算列）返回的是 INT，SQL Server 仍可能在窗口物化阶段回退到窄类型——务必在 OVER 子句的直接输入上做显式转换，而不是只在最终 SELECT 列里转。
