窗口函数：SQL里被集体遗忘的瑞士军刀

你正在面试。面试官抛出一道题："每个销售订单，我要看到金额，还要看到该销售员的累计销售额。"你脑子里闪过GROUP BY，但知道它会压缩行数。你想到自连接，但三个CTE嵌套下去已经看不懂自己在写什么。这时候如果有人说"用窗口函数"，你会先愣住——然后问：为什么没人早点告诉我？

事件现场：一个被反复踩中的坑

原文作者开篇就还原了这个场景。不是"可能遇到"，是"你会遇到"——几周后的数据分析工作，或者面试现场。问题很具体：既要保留每行明细，又要基于其他行计算新值。GROUP BY把8行压成3行，不行。自连接能写，但代码像意大利面。Python可以，但得先把数据全拉出来。

然后窗口函数出现。作者用了一个词：cheated（被欺骗感）。不是愤怒，是那种"原来有捷径"的轻微懊恼。这种情绪很真实——技术社区对基础工具的系统性忽视，让无数人白白绕路。

核心区别一句话说清：GROUP BY是8行进3行出，窗口函数是8行进8行出，每行多一个计算值。行数不变，信息增加。这个设计选择决定了它能解决什么问题。

语法骨架：OVER()就是开关

窗口函数的语法结构很固定。function_name()后面跟OVER()，里面三个可选子句：

PARTITION BY——分组，类似GROUP BY但保留行。ORDER BY——定义窗口内的行顺序。ROWS/RANGE BETWEEN——精确控制包含哪些行。没有PARTITION BY时，窗口是整个表。

作者用SQLite演示，建了一张销售表：12条记录，4个销售员，3个区域，时间跨度从1月到2月。数据量小到能一眼看完，但足够展示各种场景。

聚合函数（SUM/AVG/COUNT/MIN/MAX）加上OVER()立刻变身窗口函数。作者举的例子很业务化：公司总额、公司均值、个人总额、个人均值、个人占比。这些指标在BI报表里天天见，但很多人用子查询或自连接硬算。

代码里有个细节：ROUND(100.0 * amount / SUM(amount) OVER (PARTITION BY rep_name), 1)。这里100.0不是100，是为了强制浮点除法。SQL里这种小坑，写过的人都知道。

人物动作：为什么"没人用"

原文标题说"没人用"（Nobody Uses），作者没有直接解释原因，但从行文能反推几个逻辑。第一，教学顺序问题。SQL入门教SELECT、WHERE、GROUP BY，窗口函数被放在"高级"章节，很多人没走到那章就停了。第二，认知框架冲突。GROUP BY的思维惯性太强——"要汇总就得压行"，这个直觉错了。第三，命名障碍。"窗口函数"这个翻译本身不直观，OVER()也不像JOIN那样有画面感。

作者的身份设定是"那个告诉你的人"。全文用第二人称"你"，模拟对话感。这种写法降低心理门槛，但也暗示一个事实：技术文档的常规写法失败了，需要有人用"你会遇到这个问题"的场景来补课。

从商业逻辑看，这是典型的工具 adoption gap（采用鸿沟）。功能存在、文档齐全、性能合格，但用户不知道或不会用。数据库厂商（Oracle、PostgreSQL、SQL Server、SQLite）都实现了窗口函数，但教育市场和开发者社区没跟上。对科技从业者来说，这意味着什么？面试准备清单里缺了一项，代码审查时多了一种优化机会，技术选型时少了一个拒绝SQL的理由。

行业影响：被低估的生产力杠杆

窗口函数2003年就被写进SQL标准（ISO/IEC 9075-2:2003），但普及速度远慢于它的实用价值。PostgreSQL 8.4（2009）、SQL Server 2005、Oracle 8i（1999）陆续支持，SQLite是2018年的3.25.0版本。这个时间表说明：技术成熟度和用户认知度是两条曲线。

对25-40岁的科技从业者，这个工具的具体价值在哪？减少数据搬运——不用为了计算排名或累计值把数据导到Python。减少代码复杂度——一个OVER()替代多层CTE。减少沟通成本——SQL文件直接可读，不用解释"这段Python在算什么"。

原文没提但隐含的一个点是：现代数据栈（dbt、Looker、Metabase）的兴起，让SQL曝光度回升。窗口函数从"数据库专家技能"变成"数据分析师标配"。这个转变正在发生，但速度不够快。

作者最后留了一个开放结构——代码示例未完，但核心信息已经传递：窗口函数的存在、语法、基本用法。没有"总结三点"，没有"立即行动"，是那种"你知道了，接下来看你怎么用"的收尾。

如果窗口函数真的被大规模采用，SQL和Python在数据分析中的分工会不会重新洗牌？那些用Pandas写groupby().cumsum()的场景，有多少其实该留在数据库里完成？