窗口函数适合实时计算动态排名和累计值，数据透视表适合固定维度交叉统计报表；二者语义不同，不可混用，需先明确需求是动态明细还是静态汇总。
窗口函数适合实时计算动态排名和累计值
当你要在不打乱原始行数的前提下，给每行加一个“到当前行为止的销售额累计”或“按地区分组内的销售排名”，ROW_NUMBER()、SUM() OVER () 这类窗口函数是唯一合理选择。数据透视表做不到——它必须聚合、必须坍缩行数。
常见错误现象：GROUP BY 后硬套 ROW_NUMBER() 报错，或者把 OVER 写成 GROUP BY 的子句；本质是混淆了“分组聚合”和“分组计算但保留明细”的语义。
实操建议：
- 确认需求是否需要保留原始行：如果要查“每个订单的客户历史订单数”，就必须用
COUNT(*) OVER (PARTITION BY customer_id ORDER BY order_date) -
PARTITION BY是分组逻辑，ORDER BY在窗口内决定累计/排名顺序，漏掉ORDER BY会导致累计值变成全量和（非逐行累加） - MySQL 8.0+、PostgreSQL、SQL Server 支持完整窗口语法；SQLite 3.25+ 仅支持部分，旧版 MySQL 必须用变量模拟，性能差且不可靠
数据透视表适合固定维度交叉统计报表
你要看“各产品线在华北、华东、华南的月度销售额对比”，且结果只要一张宽表（列是区域，行是月份），PIVOT（SQL Server）或 CROSSTAB()（PostgreSQL 扩展）或手写 CASE WHEN + GROUP BY 就比窗口函数直接得多。
常见错误现象：用窗口函数强行拼宽表，比如对每个区域写一遍 SUM(CASE WHEN region='华北' THEN amount END) OVER ()，结果每行都重复输出全部区域值，还无法过滤空列。
实操建议：
- SQL Server 直接用
PIVOT，但要求聚合函数明确，且列名必须是确定值（不能用子查询动态生成） - PostgreSQL 没原生
PIVOT，常用CROSSTAB()（需启用tablefunc扩展），或更通用的CASE WHEN+MAX()/SUM()组合 - 注意 NULL 处理：
CASE WHEN方式里，没匹配上的区域默认为 NULL，要用COALESCE()包一层才好看
性能差异主要来自执行计划阶段
窗口函数通常在扫描后做一次排序或哈希分组，不改变数据流基数；而数据透视表本质是两次聚合（先分组统计，再转置），中间结果可能膨胀或收缩，优化器更容易误判。
实操建议：
- 大数据量下，
OVER (PARTITION BY x ORDER BY y)如果x基数高（比如百万级用户ID），排序开销大，考虑加联合索引(x, y) - 用
CASE WHEN实现透视时，避免在SELECT里嵌套子查询，否则每列都触发一次全表扫描 - 某些场景可混用：先用窗口函数算出明细指标（如用户最近3次下单间隔），再用
CASE WHEN按间隔范围做分布统计
别在同一个查询里又窗口又透视
有人试图在一个 SELECT 中既用 ROW_NUMBER() OVER () 又用 CASE WHEN 做列展开，结果发现排名值在透视后错位——因为窗口函数在逻辑上早于 GROUP BY / CASE WHEN 聚合阶段执行，但很多人按书写顺序理解执行顺序。
实操建议：
- 如果真要组合，先用 CTE 或子查询把窗口结果固化，再在外层做透视，避免隐式执行顺序陷阱
- PostgreSQL 中
CROSSTAB()的输入必须是两列（rowid + category/value），不能直接喂一个带窗口函数的结果集，得先SELECT rowid, cat, val FROM (... WINDOW ...) t - MySQL 用户尤其小心：8.0 之前没有窗口函数，硬凑变量 + 自连接做排名，再叠加 CASE 透视，极易因连接条件漏写导致笛卡尔积
真正难的是判断“这个需求到底该用哪条路走通”——不是语法会不会，而是想清楚你要的是随行变化的动态值，还是固定结构的汇总快照。前者窗口函数绕不开，后者硬上窗口只会让 SQL 越写越歪。
