窗口函数比关联子查询快，因其仅需一次排序和线性遍历，将数据读取量从O(n²)降至O(n log n)，避免每行触发独立全表扫描。
窗口函数比关联子查询快，核心原因是避免重复扫描
关联子查询在 WHERE 或 SELECT 中每行都触发一次独立执行，比如查每个员工工资排名时写成 (SELECT COUNT(*) FROM emp e2 WHERE e2.salary > e1.salary)，数据库就得对每一行 e1 重新全表扫一遍 e2。而窗口函数如 ROW_NUMBER() OVER (ORDER BY salary DESC) 只需一次排序、一次线性遍历，数据读取量直接从 O(n²) 降到 O(n log n)。
常见错误现象：
- 查询耗时随数据量非线性暴涨，10 万行就卡住
- 执行计划里反复出现 DEPENDENT SUBQUERY（MySQL）或 Correlated Subplan（PostgreSQL）
- EXPLAIN 显示扫描行数是表总行数的几倍甚至几十倍
实操建议：
- 能用 ROW_NUMBER()、RANK()、LAG()、SUM() OVER () 实现的逻辑，优先不用子查询
- 注意窗口函数不能直接用于 WHERE —— 比如想筛“排名前 10”，得套一层 CTE 或子查询：SELECT * FROM (SELECT *, ROW_NUMBER() OVER (...) rn FROM t) t2 WHERE t2.rn
- MySQL 8.0+、PostgreSQL 8.4+、SQL Server 2005+ 都支持标准窗口函数；SQLite 3.25+ 也支持，但旧版不支持
<h3>关联子查询有时无法被优化器重写为连接</h3>
优化器理论上能把某些关联子查询转成 JOIN，但实际中常失败，尤其当子查询含聚合、DISTINCT、GROUP BY 或嵌套层级深时。比如 SELECT name, (SELECT AVG(salary) FROM dept d2 WHERE d2.dept_id = e.dept_id)，即使 dept_id 有索引，优化器也可能放弃重写，坚持逐行求值。
使用场景差异： - 关联子查询适合“单值判断”且结果集极小（如查某个配置开关是否开启） - 窗口函数适合“基于整组数据计算当前行衍生值”，比如累计求和、移动平均、分组内排序
性能影响明显：
- 同样逻辑下，窗口函数通常快 3–10 倍，数据量越大差距越显著
- 关联子查询容易触发临时表或磁盘排序（Using temporary; Using filesort），窗口函数更倾向内存计算
- PostgreSQL 中，关联子查询可能阻止并行执行计划，而窗口函数可参与并行化（需开启 max_parallel_workers_per_gather）
别忽略 PARTITION BY 和 ORDER BY 的开销
PARTITION BY 本身不慢，但一旦搭配 ORDER BY（尤其是没索引字段），就会强制排序——这可能是窗口函数唯一的重头开销。例如 AVG(salary) OVER (PARTITION BY dept_id ORDER BY hire_date)，若 hire_date 无索引，就得为每个部门单独排序。
容易踩的坑：
- 误以为加了 PARTITION BY 就一定比子查询快，其实如果分区键高基数（比如按 user_id 分），且没索引，照样慢
- 忘记 ORDER BY 在窗口函数里不是“最终结果排序”，只是定义窗口内顺序；最终输出顺序仍需外层 ORDER BY
- 在 MySQL 中，OVER () 空括号表示全表范围，但若没加 ORDER BY，ROW_NUMBER() 结果不可靠（无稳定顺序）
实操建议：
- 对常用 PARTITION BY + ORDER BY 字段建联合索引，例如 CREATE INDEX idx_dept_hire ON emp(dept_id, hire_date)
- 如果只想要分组统计值（不要顺序敏感计算），去掉 ORDER BY，比如用 COUNT(*) OVER (PARTITION BY dept_id) 而非带 ORDER BY 版本
- 测试时用 EXPLAIN ANALYZE（PostgreSQL）或 EXPLAIN FORMAT=JSON（MySQL）看实际是否用了索引、是否触发排序
兼容性陷阱：老版本数据库根本不认窗口函数
MySQL 5.7 及更早、SQL Server 2000–2003、Oracle 8i–9i 这些环境压根不支持 OVER 语法。强行写会报错：ERROR 1064 (42000): You have an error in your SQL syntax 或 ORA-30483: window functions are not allowed here。
应对办法很实在：
- 先确认目标数据库版本：SELECT VERSION()（MySQL）、SELECT @@VERSION（SQL Server）
- 若必须兼容旧版本，关联子查询反而是唯一选择，但要加索引兜底，比如在子查询的关联字段上建索引
- 不要用“模拟窗口函数”的自连接写法（如 LEFT JOIN 自身来数排名），它本质还是 O(n²)，且更难维护
真正麻烦的是混合环境：应用连着多个数据库实例，有些是 MySQL 5.7，有些是 8.0。这时候没法统一用窗口函数，得在代码层做方言适配，或者把逻辑下沉到应用里计算——但那就脱离 SQL 优化范畴了。
事情说清了就结束。窗口函数不是银弹，但它在支持它的环境里，确实是替代关联子查询最直接、最有效的降本增效手段；而最容易被忽略的，其实是那个没索引的 ORDER BY 字段——它能让窗口函数从飞驰变成爬行。
