SQL性能调优：为何尽量使用窗口函数而非关联子查询

窗口函数比关联子查询快，因其仅需一次排序和线性遍历，将数据读取量从O(n2)降至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(n2) 降到 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 无索引，就得为每个部门单独排序。 WisPaper 复旦大学研发的AI学术搜索工具，5分钟内筛选1000篇论文