窗口函数比Python循环快，因其由数据库引擎在C层单次扫描完成分区、排序与计算，而Python需全量拉取数据至内存逐行处理，导致网络传输、序列化及内存开销巨大。
窗口函数在大数据ETL中比Python循环快，根本原因不是“语法更短”，而是执行模型完全不同：窗口函数由数据库引擎在C层单次扫描完成分区、排序与计算，而Python循环意味着把全部原始数据拉到内存里，再用解释器逐行处理——光是网络传输和序列化开销就已不可逆地拖垮性能。
为什么Python循环在ETL里天然慢
ETL场景下，Python循环（比如用for row in df.itertuples()）本质是把整张表从数据库取出来，再在本地做行级逻辑。这带来三重硬伤：
- 数据搬运成本高：1000万行 × 每行2KB = 至少20GB网络传输 + 内存加载，数据库端压力小，但Python进程可能OOM
- 无法利用索引和统计信息：数据库优化器对
WHERE、JOIN、GROUP BY的路径选择完全失效，全靠Python硬算 - 无并行加速能力：
for循环默认单线程；即使上concurrent.futures，也得自己拆分数据、合并结果，逻辑复杂且易出错
窗口函数如何在数据库内完成ETL核心逻辑
真正高效的ETL，是让计算尽量靠近数据。窗口函数正是这种“推式计算”的典型代表，它把原本要写成Python循环的逻辑，直接下推到数据库执行层：
-
LAG(order_amount, 1) OVER (PARTITION BY user_id ORDER BY order_time)：直接在数据库内按用户分组、按时间排序后取上一行，无需Python读取全量订单再排序再遍历 -
SUM(revenue) OVER (PARTITION BY region ORDER BY date ROWS BETWEEN 29 PRECEDING AND CURRENT ROW)：30天滚动求和，数据库用滑动窗口算法一次扫描完成，不是每次查30行再sum -
ROW_NUMBER() OVER (PARTITION BY batch_id ORDER BY created_at DESC)：每个批次取最新一条记录，比用Python去重或groupby().apply(lambda x: x.nlargest(1, 'created_at'))快一个数量级以上
常见误用：以为写了窗口函数就等于高效
窗口函数不是银弹，写错照样慢甚至报错：
macOS UI 自动化技能包 —— 用 Python 控制你的 Mac
下载
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 漏掉
ORDER BY却依赖顺序：比如LAG(col)没指定ORDER BY，结果随机，调试时难复现 -
PARTITION BY字段无索引 +ORDER BY字段也无索引：数据库被迫为每个分区单独排序，磁盘临时文件暴涨 - 在MySQL 5.7或旧版PostgreSQL中硬用：这些版本不支持窗口函数，语句直接报
ERROR 1064或被降级为关联子查询 - 把窗口函数塞进
WHERE：如WHERE ROW_NUMBER() OVER (...) 会报错，必须套一层CTE或子查询
什么时候该切回Python处理
不是所有ETL逻辑都适合窗口函数。以下情况建议留在Python侧：
- 需要调用外部API或非SQL函数（如调用NLP模型打标）
- 逻辑含大量条件分支、状态机或递归（比如订单状态流转校验）
- 输入是多源异构数据（CSV + JSON + DB），且无法统一建模为关系表
- 窗口函数输出后仍需做Pandas特有的操作（如
pd.qcut()分箱、sklearn特征缩放）
真正的高效ETL，是把能下推的计算（排序、累计、排名、前后行差值）全交给SQL窗口函数，只把必须用Python表达的逻辑留在最后一步。别在数据库里硬写Python思维，也别在Python里硬搬数据库能力——边界感，才是性能的分水岭。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
