窗口函数不可多重嵌套，必须用CTE或子查询拆解；分母需匹配占比粒度，用PARTITION BY控制，乘100.0防整除，NULLIF防除零，时间维度需标准化周期字段。
窗口函数不能直接多重嵌套，必须用 CTE 或子查询拆解
SQL 标准明确禁止在 OVER() 子句里再写窗口函数，比如 ROW_NUMBER() OVER (ORDER BY SUM(sales) OVER (PARTITION BY region)) 这种写法，所有主流引擎（PostgreSQL / MySQL 8+ / SQL Server / BigQuery）都会报错 Window function is not allowed in window definition。这不是数据库厂商的 bug，而是语法层面的硬性限制。
真正能跑通的路径只有一条：先算出内层结果，再在外层对这个中间结果应用窗口函数。CTE 是最推荐的方式，逻辑清晰、可调试、避免重复计算。
- 错误写法：
SELECT region, city, SUM(amount) / SUM(SUM(amount)) OVER (PARTITION BY region) FROM sales GROUP BY region, city—— 外层SUM(SUM())在OVER里非法 - 正确写法（CTE）：
WITH region_city_sum AS ( SELECT region, city, SUM(amount) AS city_sum FROM sales GROUP BY region, city ) SELECT region, city, city_sum, ROUND(city_sum * 100.0 / SUM(city_sum) OVER (PARTITION BY region), 2) AS pct_in_region FROM region_city_sum;
- 如果只用子查询，记得加别名，否则 MySQL/PostgreSQL 会报
subquery in FROM must have an alias
多维占比必须显式处理分母粒度和 NULL
占比本质是「分子 / 分母 × 100」，而分母必须严格对应你要表达的“整体”范围。比如算「城市占所在地区的比例」，分母就得是该地区的总和，不是全表总和，也不是按时间分组后的总和——PARTITION BY region 就是这个关键控制点。
另外两个高频坑：一是整数除法导致结果为 0（比如 SUM(amount) / SUM(total) 全是整型），二是分母为 0 或 NULL 导致整列变 NULL。
- 乘
100.0而不是100，强制转为浮点运算：ROUND(numerator * 100.0 / denominator, 2) - 分母用
SUM() OVER (PARTITION BY ...)，别用GROUP BY后的聚合字段，否则无法保行 - 加
NULLIF(denominator, 0)防除零，或用CASE WHEN denominator = 0 THEN 0 ELSE ... END - 空值默认被归入同一分区，如需排除，先
WHERE region IS NOT NULL AND city IS NOT NULL
交叉维度占比（如地区×时间）要先对齐周期字段
当占比维度涉及时间（比如「某月销售额占该地区本季度总和的比例」），不能直接 ORDER BY order_time 或 GROUP BY YEAR(order_time), QUARTER(order_time) —— 这会导致跨年季度错乱（如 2024-Q4 和 2025-Q1 被混在一起）。
必须先生成标准周期字段，再用于 PARTITION BY。不同数据库方案略有差异：
- PostgreSQL 14+ 推荐用
date_bin('3 months', order_time, '2024-01-01')，第三个参数是基准起点，不可省略 - MySQL / 旧版 PG 可用
DATE_FORMAT(order_time, '%Y-%q')或CONCAT(YEAR(order_time), '-', QUARTER(order_time))，但要注意字符串排序是否自然（'2024-1' - 更稳妥的做法是用整数表示周期：
YEAR(order_time) * 10 + QUARTER(order_time)，确保 20241
生成后，在 CTE 中按该字段和 region 联合 PARTITION BY 即可。
性能敏感时，注意窗口函数的排序复用
一个查询里如果有多个窗口函数，且它们的 PARTITION BY 和 ORDER BY 完全一致，优化器通常能复用一次排序结果；但只要有一个字段不同（比如一个按 region, city 分区，另一个只按 region），就可能触发多次排序扫描，千万级表上耗时翻倍很常见。
实际写法中，优先合并逻辑相近的窗口计算，减少独立 OVER 子句数量。
- 能用一个
SUM() OVER (PARTITION BY region, city)解决的，别拆成两个分别PARTITION BY region和PARTITION BY city - 若必须多维度占比（如同时算「占地区比」和「占全表比」），至少让它们共用同一个
ORDER BY字段（哪怕不真需要排序），有助于优化器复用 - 在 PostgreSQL 中，可以用
EXPLAIN ANALYZE看执行计划里是否有多个WindowAgg节点，确认是否重复排序
最复杂的点往往不在语法，而在于你是否清楚自己想表达的「占比分母」到底属于哪一层业务逻辑——是静态全量？动态分区？还是带时间滚动的？没对齐这一层，后面所有嵌套和计算都是空中楼阁。
