Django 4.2中Window函数必须用Window类显式构造，expression只能是聚合函数，partition_by和order_by需明确指定，且多个Window共存时应统一partition_by和order_by以优化性能。
Window函数在Django 4.2中必须用Window类显式构造
Django 4.2 原生支持开窗函数，但不像 SQL 那样直接写 OVER (PARTITION BY ... ORDER BY ...)，必须通过 Window 类包裹聚合表达式。漏掉 Window 就会变成普通聚合，结果完全错误。
常见错误是把 Sum('amount') over (partition by user_id order by created_at) 直接当字段传进 .annotate()，结果报错或返回单值——因为 Django 不识别裸的 over 语法。
- 必须用
Window(expression, partition_by=[...], order_by=[...])显式声明窗口逻辑 -
expression只能是聚合函数（如Sum、Avg、RowNumber），不能是普通字段 -
partition_by和order_by接收字段名字符串或F对象，比如'user_id'或F('user__id') - 不指定
order_by时，某些数据库（如 PostgreSQL）允许，但 MySQL 8+ 会报错，建议始终显式声明
RowNumber和Rank的区别直接影响分组内排序行为
RowNumber 和 Rank 都生成序号，但处理并列值的方式不同：前者严格递增（1,2,3），后者跳过重复位次（1,1,3）。选错会导致业务逻辑偏差，比如“每个用户消费金额 Top 3”这种需求，用 Rank 会多返回并列第 3 名的记录。
实操中容易忽略 order_by 的方向——默认升序，而多数排名场景需要降序，必须写成 order_by=F('amount').desc()。
立即学习“Python免费学习笔记（深入）”；
-
RowNumber：适合唯一排序（如按时间戳严格先后），不可用于并列排名场景 -
Rank：适合“并列同名次”，但后续名次会跳过，例如 [100,100,90] → [1,1,3] -
DenseRank：并列不跳过，[100,100,90] → [1,1,2]，更贴近“前 N 名”的直觉 - 所有排名函数都必须配合
order_by，否则报DatabaseError: window function requires an OVER clause with ORDER BY
多个Window注解共存时注意子查询嵌套与性能
Django 会为每个 Window 构造独立的窗口计算，在 SQL 层表现为多个 OVER 子句并列。这本身没问题，但若同时用 RowNumber + Sum + Avg，且 partition_by 不一致，数据库可能无法复用排序缓存，导致性能下降。
尤其在大表上，order_by 字段没索引时，PostgreSQL 会触发额外的 Sort 节点；MySQL 则可能拒绝执行或极慢。
- 尽量让多个
Window的partition_by和order_by保持一致，便于数据库优化 - 对高频使用的
order_by字段（如created_at、user_id）建立复合索引，例如Index(fields=['user_id', 'created_at']) - 避免在
Window中引用未在GROUP BY中出现的非聚合字段，否则 SQLite 会报错，PostgreSQL 可能返回意外结果 - 调试时可用
print(str(queryset.query))查看生成的 SQL，确认窗口子句是否符合预期
跨模型关联字段在Window中要谨慎使用F表达式
想按外键关联字段分组（比如按 User.profile.city 统计），不能直接写 partition_by=['user__profile__city'] —— Django 4.2 的 Window 不支持双下划线路径，必须用 F 表达式提前 annotate 出来。
否则会报 FieldError: Cannot resolve keyword 'user__profile__city' into field，这个错误信息不提示根本原因，容易卡住。
- 先
.annotate(city=F('user__profile__city'))，再Window(..., partition_by=['city']) - 如果关联字段可能为空（
NULL），注意partition_by会把所有NULL归为同一组，影响结果分布 - 涉及
select_related或prefetch_related不影响Window执行，因为开窗在数据库层完成，关联只是预加载，两者正交 - MySQL 8.0.22+ 支持开窗，但对复杂关联的支持弱于 PostgreSQL，测试阶段务必在目标数据库上验证
.annotate() 中，不能放在 .filter() 或 .values() 后链式调用里临时加——它只在 annotate 阶段生效。一旦忘了这层约束，查半天也看不出为什么字段没出来。 
