EXCLUDE控制窗口函数计算时是否将当前行或同组/同值行纳入窗口范围，仅在显式定义frame_clause（如ROWS/RANGE）时生效；默认无frame_clause则被忽略。
EXCLUDE在窗口帧中到底控制什么
EXCLUDE不是用来跳过某些行的过滤条件，而是告诉PostgreSQL：当计算当前行的窗口函数值时，要不要把“当前行自身”或“同组内某些边界行”算进窗口范围里。它只在显式定义了frame_clause（比如ROWS BETWEEN ...）的前提下才生效；没写frame_clause时，PostgreSQL按默认规则处理，EXCLUDE直接被忽略。
EXCLUDE语法与常见组合陷阱
合法的EXCLUDE取值只有四个：NO OTHERS（默认）、CURRENT ROW、GROUP、TIES。最容易出错的是误以为EXCLUDE CURRENT ROW能“排除当前行后重新计算”，其实它只是把当前行从窗口中拿掉——但ORDER BY和PARTITION BY逻辑完全不变，排序位置、分组归属都不受影响。
-
EXCLUDE CURRENT ROW：当前行不参与计算，但仍在窗口排序中占位（比如LAG()结果不受影响，但SUM() OVER (... EXCLUDE CURRENT ROW)会少加自己） -
EXCLUDE GROUP：仅在使用RANGE帧且存在ORDER BY重复值时有效；它会把所有和当前行ORDER BY值相同的行都排除，不只是当前行 -
EXCLUDE TIES：比GROUP更激进，只要ORDER BY值相同，不管是否在当前窗口范围内，全部排除——但必须配合RANGE，ROWS下无效 - 错误用法：
EXCLUDE不能单独出现，必须跟在frame_clause之后，例如ROWS BETWEEN 1 PRECEDING AND 1 FOLLOWING EXCLUDE CURRENT ROW；写成OVER (PARTITION BY x ORDER BY y EXCLUDE CURRENT ROW)会报错
EXCLUDE对执行计划和性能的实际影响
加EXCLUDE几乎不改变执行计划结构，但可能显著影响中间结果集大小和内存占用。尤其当窗口帧本身已经很大（如UNBOUNDED PRECEDING），再用EXCLUDE GROUP或TIES，PostgreSQL必须缓冲更多“潜在同值行”来判断是否排除，容易触发Window Spool落到磁盘。
- 验证方式：运行
EXPLAIN (ANALYZE, BUFFERS)，重点看WindowAgg节点的Buffers读写量是否突增 - 索引仍最关键：即使用了
EXCLUDE，如果PARTITION BY + ORDER BY列没联合索引，全表扫描和排序照旧发生，EXCLUDE只是在那之后做“减法” - 慎用
EXCLUDE TIES：它要求PostgreSQL扫描整个PARTITION找所有同值行，而不是仅限当前帧，数据量大时延迟明显
真实场景中该不该用EXCLUDE
绝大多数业务需求其实不需要EXCLUDE。比如计算移动平均、累计求和、排名，用默认行为或调整frame_clause就够了。真正需要它的场景很窄：比如风控系统中，要统计“除当前交易外，过去1小时内的同类操作次数”，这时EXCLUDE CURRENT ROW才是语义准确的解法。
- 替代方案更常用：想排除当前行效果，往往用
LAG()/LEAD()更清晰；想跳过NULL，用IGNORE NULLS（PostgreSQL 16+支持LAST_VALUE(... IGNORE NULLS)） - 兼容性注意：MySQL 8.0和SQL Server支持
EXCLUDE，但SQLite不支持；跨数据库迁移时，含EXCLUDE的SQL大概率要重写 - 调试建议：先用
NO OTHERS跑通逻辑，再逐步替换为EXCLUDE并对比结果差异——因为EXCLUDE GROUP和TIES的行为在重复值密集时极难肉眼预判
