窗口函数性能通常优于关联子查询，因其仅需一次全表扫描、一次排序和一次线性遍历，而关联子查询会对外层每行重复执行内层逻辑，导致10万行时可能扫描千万级行数。
窗口函数性能明显优于关联子查询，尤其在数据量超过10万行时，差距可达3–10倍；但前提是写法正确、索引到位，否则可能比简单子查询还慢。
为什么窗口函数通常更快
核心在于执行模型差异：窗口函数只做一次全表扫描 + 一次排序 + 一次线性遍历；而关联子查询（如 WHERE x = (SELECT ...) 或 SELECT ..., (SELECT ...)）会让数据库对外层每行都触发一次内层独立执行——10万行外层，就可能执行10万次内层扫描或排序。
常见错误现象包括：
-
EXPLAIN中反复出现DEPENDENT SUBQUERY（MySQL）或Correlated Subplan（PostgreSQL） -
Rows列数值爆炸式增长，比如表只有50万行，但执行计划显示扫描了2000万行 - 查询耗时随数据量非线性暴涨，10万行开始明显卡顿
实操建议：
- 能用
ROW_NUMBER()、SUM() OVER、LAG()实现的逻辑，优先不写关联子查询 - 避免把窗口函数当“语法糖”硬套——比如纯统计总条数，
COUNT(*) OVER ()比SELECT COUNT(*)多出WindowAgg节点开销 - 窗口函数不能直接用于
WHERE过滤（如筛排名前10），必须嵌套一层：SELECT * FROM (SELECT *, ROW_NUMBER() OVER (...) rn FROM t) t2 WHERE t2.rn
PARTITION BY 和 ORDER BY 的索引影响
窗口函数真正的性能瓶颈不在函数本身，而在 PARTITION BY 和 ORDER BY 字段是否走索引。没索引时，每个分区都要单独排序，代价可能远超子查询。
例如：AVG(salary) OVER (PARTITION BY dept_id ORDER BY hire_date)，若 hire_date 无索引，数据库就得为每个部门重建有序序列。
实操建议：
- 为
PARTITION BY + ORDER BY字段建复合索引，如(dept_id, hire_date) - 时间字段有重复值时，务必加二级排序，如
ORDER BY event_time DESC, id DESC，否则 MySQL 8.0 每次返回“前一行”可能不同 -
ROWS UNBOUNDED PRECEDING必须显式写，别省略——RANGE在日期字段上会把同一天所有行都纳入，导致累计值虚高
哪些场景子查询反而更合适
不是所有子查询都该被替换。以下情况关联子查询更合理：
- 单值判断且结果集极小，比如
WHERE status = (SELECT value FROM config WHERE key = 'enable_feature') - 子查询只查一行、有主键/唯一索引驱动，优化器能转成高效半连接（
SEMI JOIN） - 业务逻辑天然分步，比如先算中间指标再过滤，此时用 CTE 比强行塞进一个窗口函数更清晰
注意：含 GROUP BY、DISTINCT 或多层嵌套的关联子查询，优化器大概率无法重写为 JOIN，会坚持逐行求值——这种必须改。
真正容易被忽略的点是：窗口函数快的前提是内存足够完成排序；一旦溢出到磁盘临时表，性能断崖下跌。所以别只看语法优雅，得盯紧 EXPLAIN ANALYZE 里的 WindowAgg 耗时占比和 Using temporary; Using filesort 是否出现在窗口节点里。
