子查询模拟ROW_NUMBER()错乱，因未关联外层表且缺少唯一排序条件，导致计数逻辑错误；必须用相关子查询并确保ORDER BY字段组合唯一，如(SELECT COUNT(*) FROM t2 WHERE t2.sort_col > t1.sort_col OR (t2.sort_col = t1.sort_col AND t2.id > t1.id)) + 1。
子查询模拟 ROW_NUMBER() 时为什么结果错乱
直接用 (SELECT COUNT(*) FROM t2 WHERE t2.id 看似能编号，但只要 id 不唯一或没加排序依据，编号就不可靠。旧版 MySQL 或 SQL Server 2005 之前不支持 ORDER BY 在子查询中影响外层逻辑，所以必须把排序条件显式“翻译”进子查询的 WHERE 和 AND 条件里。
实操建议：
- 先确认主排序字段组合是否唯一；若不唯一（比如按
created_at排序但存在毫秒级重复），必须引入辅助唯一字段（如自增id）构成复合排序键 - 模拟
ROW_NUMBER() OVER (ORDER BY a, b)时，子查询要写成：SELECT COUNT(*) + 1<br>FROM t2<br>WHERE t2.a OR (t2.a = t1.a AND t2.b OR (t2.a = t1.a AND t2.b = t1.b AND t2.id
- 避免在子查询中用
!=或NOT IN做排除——NULL 值会让整个计数崩掉
用相关子查询替代 RANK() 和 DENSE_RANK()
RANK() 要跳过并列后的序号，DENSE_RANK() 则不跳。两者都不能靠简单计数实现，必须先算出“当前行值之前有多少个更小的值”，再结合“当前值出现几次”来修正。
实操建议：
- 模拟
RANK()：先统计严格小于当前值的记录数n，再加 1；等价于n + 1 - 模拟
DENSE_RANK()：统计有多少个“不同的值比当前值小”，再加 1；需用(SELECT COUNT(DISTINCT col) FROM t2 WHERE t2.col - 如果排序字段允许 NULL，
WHERE t2.col 会自动过滤 NULL，但你要决定 NULL 是排最前还是最后——得额外用UNION或CASE处理
性能陷阱：子查询在 WHERE 和 SELECT 中的开销差异
把窗口模拟写在 SELECT 子句里（即相关子查询），数据库会对每一行执行一次子查询；而如果误写成 WHERE 中的子查询（比如想筛出“每组 top 3”），可能触发全表扫描嵌套，慢到超时。
实操建议：
- 优先用
JOIN+ 自连接替代多层相关子查询，例如模拟分组内序号可写成：SELECT t1.*, COUNT(t2.id) + 1 AS rn<br>FROM orders t1<br>LEFT JOIN orders t2<br> ON t1.customer_id = t2.customer_id<br> AND (t2.total > t1.total<br> OR (t2.total = t1.total AND t2.id GROUP BY t1.id, t1.customer_id, t1.total
- 确保参与比较的字段都有索引，特别是用于
JOIN和WHERE的复合条件字段 - MySQL 5.6+ 可用
EXPLAIN FORMAT=TREE看是否用了“dependent subquery”——出现这个就说明性能危险
兼容性边界：哪些窗口逻辑根本没法安全模拟
不是所有窗口函数都能被子查询覆盖。最典型的是 LAG()/LEAD() 和带 ROWS BETWEEN 的聚合窗口，因为它们依赖物理行序或滑动范围，而子查询无法表达“上一行的某个字段值”这种状态引用。
实操建议：
- 遇到
LAG(col, 1)，只能靠自连接找“本组中 id 刚好比当前小 1 的那行”，前提是id是连续且无删减的——现实中几乎不成立 - 想模拟
SUM(col) OVER (ORDER BY ts ROWS BETWEEN 2 PRECEDING AND CURRENT ROW)？放弃。这种必须升级数据库或改用应用层计算 - 如果业务强依赖这类功能，与其硬扛子查询，不如用临时表 + 变量（MySQL）或游标（SQL Server），虽然丑但可控
真正麻烦的从来不是怎么写，而是怎么证明它在所有边界数据下都和原窗口函数行为一致——尤其是空值、重复值、超大数据量时的执行计划漂移。
