SQL中无窗口函数时，可通过自连接或相关子查询模拟RANK()和ROW_NUMBER()：对每行统计排序更优的记录数加1，RANK()用严格比较，ROW_NUMBER()需加唯一键区分；分组排名用LEFT JOIN+GROUP BY；DENSE_RANK()用COUNT(DISTINCT)；性能依赖索引，优先使用窗口函数。
SQL 中没有窗口函数时怎么实现 RANK() 或 ROW_NUMBER()
MySQL 5.7 或更早版本、SQLite（默认不支持）、某些嵌套子查询受限的 OLAP 场景下，RANK() 和 ROW_NUMBER() 直接不可用。必须靠自连接或相关子查询模拟。
核心思路是：对每条记录，统计“排序条件更优”的记录数量，再加 1。比如按 score 降序排名，就数有多少条 score > 当前行 score 的记录。
- 写法示例（MySQL 5.7）：
SELECT a.name, a.score, (SELECT COUNT(*) + 1 FROM students b WHERE b.score > a.score) AS rank_num FROM students a ORDER BY a.score DESC; - 注意
b.score > a.score是严格大于，所以并列分数会得到相同排名（模拟RANK()）；若要ROW_NUMBER()效果，需额外加唯一键比较，如b.score > a.score OR (b.score = a.score AND b.id - 性能极差：子查询对每行都全表扫描，10k 行可能触发 O(n²) 复杂度，线上环境慎用
JOIN 实现多字段分组内排名（如每个部门按薪资排名）
单纯用子查询难处理“分组内排名”，因为需要限制统计范围。这时 JOIN 更可控——先 JOIN 出同组所有记录对，再聚合计数。
关键点在于 JOIN 条件既要限定分组（a.dept = b.dept），又要表达排序逻辑（b.salary > a.salary）。
- 示例（部门内薪资降序排名）：
SELECT a.name, a.dept, a.salary, COUNT(b.salary) + 1 AS dept_rank FROM employees a LEFT JOIN employees b ON a.dept = b.dept AND b.salary > a.salary GROUP BY a.name, a.dept, a.salary ORDER BY a.dept, a.salary DESC; -
LEFT JOIN保证即使最高薪员工（没人比他高）也能保留，COUNT(b.salary)对空匹配返回 0，+1 后得 1 - 如果存在薪资相同的人，此写法会给出相同排名（即
RANK()行为）；要DENSE_RANK()需改用COUNT(DISTINCT b.salary) - 注意：JOIN 字段必须有索引，否则
a.dept = b.dept AND b.salary > a.salary无法走联合索引，性能雪崩
MySQL 8.0+ 或 PostgreSQL 中 JOIN 和窗口函数混用的典型误用
有人试图在已有窗口函数的环境下，还硬套 JOIN 实现排名，结果反而出错或低效。
常见错误包括：在 OVER(PARTITION BY ...) 已能解决分组排名时，仍写冗余 JOIN；或在窗口函数结果上再 JOIN 做二次计算，引发重复行或 NULL。
- 正确做法：优先用
ROW_NUMBER() OVER(PARTITION BY dept ORDER BY salary DESC)，它比 JOIN 快一个数量级，且语义清晰 - JOIN 仅在以下情况必要：需同时引用排名前/后行的其他字段（如“上一名的姓名”），而窗口函数的
LAG()/LEAD()不够用时 - 危险组合：
SELECT *, ROW_NUMBER() OVER(...) AS rnk FROM t1 JOIN t2 ON ...—— 若 JOIN 导致主表行膨胀，ROW_NUMBER()会在膨胀后的结果集上计算，不是你想要的“原表内排名”
PostgreSQL 中用 LATERAL JOIN 模拟动态排名条件
当排名逻辑依赖运行时参数（比如用户传入的基准分、动态权重），普通窗口函数写死，而 JOIN 可结合 LATERAL 灵活构造。
LATERAL 允许右侧子查询引用左侧列，适合把“每行的排名基准”作为变量传入。
- 示例：对每个学生，计算其分数超过班级平均分多少分，并按该差值排名
SELECT s.name, s.score - avg_score.avg AS diff, ROW_NUMBER() OVER (ORDER BY s.score - avg_score.avg DESC) AS rank_by_diff FROM students s, LATERAL (SELECT AVG(score) AS avg FROM students WHERE class_id = s.class_id) AS avg_score; - 注意逗号 JOIN 是 PostgreSQL 对
CROSS JOIN LATERAL的简写，等价于显式写CROSS JOIN LATERAL - 不能用普通 JOIN 替代：因为
AVG(score)需按s.class_id动态分组，普通 JOIN 无法关联到当前行的class_id -
LATERAL子查询执行次数 = 左侧行数，若 avg_score 查询未命中索引，同样会慢
实际用 JOIN 做排名，本质是在弥补窗口函数缺失或应对动态条件。但只要数据库支持标准窗口函数，就别绕路——JOIN 排名是退路，不是首选。真正容易被忽略的，是 JOIN 条件里那个隐含的索引需求：没索引，再正确的逻辑也会在 10 万行时卡死。
