窗口函数可替代三类自连接：ROW_NUMBER()取每组最新/最旧记录、LAG()/LEAD()做相邻行比较、聚合函数OVER()替代标量子查询；但跨组关联、递归查询、含函数的动态关联及已优化索引场景仍需自连接。
ROW_NUMBER() 替代“每组取最新/最旧记录”的自连接
查每个用户最新订单、每个商品最近一次上架价——这类需求传统写法是 NOT EXISTS 或 LEFT JOIN 找不到更大时间戳的行，逻辑绕且容易漏掉并列时间。用 ROW_NUMBER() 直接分组排序标号，再过滤 rn = 1，语义清晰、结果确定。
-
PARTITION BY user_id必须和原关联条件（如o2.user_id = o1.user_id）严格一致，否则分组错位 -
ORDER BY created_at DESC, id DESC是硬性要求：时间相同时靠id保序，避免同秒多单导致每次执行结果不一致 - MySQL 5.7 不支持，必须 MySQL 8.0+、PostgreSQL、SQL Server 2012+；SQLite 需 3.25+
- 如果表没建
(user_id, created_at, id)复合索引，ROW_NUMBER()会触发磁盘排序，比原自连接还慢
LAG()/LEAD() 替代“相邻行比较”的自连接
计算同一用户两次登录间隔、股价日涨跌幅、订单金额环比变化——传统做法是 JOIN t1 ON t1.id = t2.id - 1，但 ID 不连续就崩。用 LAG() 直接取前一行值，不依赖物理顺序，只依赖 ORDER BY 定义的逻辑顺序。
-
LAG(amount, 1, 0)第三个参数是默认值，防止首行返回NULL污染后续计算（比如做减法变成NULL） -
ORDER BY login_date必须显式写出，且字段不能含大量NULL；SQL Server 不支持NULLS LAST，得用ORDER BY login_date DESC, (login_date IS NULL) ASC兜底 - Oracle 和 PostgreSQL 对
NULL排序行为一致；MySQL 8.0 在ORDER BY含NULL时可能返回非预期顺序
COUNT()/SUM()/AVG() OVER(PARTITION BY ...) 替代标量子查询
把 (SELECT AVG(salary) FROM emp e2 WHERE e2.dept = e1.dept) 这类子查询塞进 SELECT 列表，等于每行都触发一次独立扫描。换成 AVG(salary) OVER (PARTITION BY dept)，数据库单次遍历完成全部计算。
-
PARTITION BY dept和子查询里的WHERE e2.dept = e1.dept必须字段名、大小写、NULL处理完全对齐；dept为NULL时，窗口函数会把所有NULL归成一组，而传统子查询中NULL = NULL为UNKNOWN，不匹配——要用COALESCE(dept, 'N/A')统一对齐 - 不能在
WHERE或HAVING中直接引用窗口函数别名，比如WHERE dept_avg > 10000会报错；必须包一层子查询或 CTE - 滚动计算（如 7 日销售额）必须用
ROWS BETWEEN 6 PRECEDING AND CURRENT ROW，仅靠ORDER BY不够，否则算的是从第一行到当前行的累计值
哪些自连接根本不能用窗口函数替代？
窗口函数不是万能的，它只解决「同表、分组内、行间计算」这一类问题。一旦涉及跨组、多跳、条件复杂关联，强行套用反而更错。
- 需要关联不同分组的数据，比如“把 A 部门工资最高的人和 B 部门入职最早的人配对”，这必须用
JOIN或CTE - 经理的经理、组织架构向上递归三级，得用递归
WITH RECURSIVE，LAG()最多回溯固定偏移量 - 关联条件含函数或表达式，比如
ON YEAR(o1.created_at) = YEAR(o2.created_at) - 1，窗口函数无法动态定义分区边界 - 原自连接本身已加高效覆盖索引（如
(user_id, created_at)），而窗口函数触发全表排序且内存不足，IO 成瓶颈——这时别硬换
实际改写时最容易被忽略的点是：窗口函数在 SQL 执行顺序中位于 WHERE 之后，无法提前过滤数据。如果你的原始自连接靠 WHERE 先筛掉 90% 行，再关联剩余小结果集，那窗口函数可能被迫对全表排序，性能反降。务必先看执行计划里的 Sort 成本，而不是只数代码行数。
