标量子查询可通过统计同组中排序字段更小（或相等）的记录数模拟ROW_NUMBER()效果，如(SELECT COUNT(*) FROM employees e2 WHERE e2.dept = e1.dept AND e2.salary >= e1.salary) AS rank。
标量子查询怎么给每组数据加行号
标量子查询本身不生成行号，但可以模拟 ROW_NUMBER() 的效果——前提是数据库不支持窗口函数，或你必须在 WHERE/HAVING 中动态引用排名值。核心思路是：对当前行，统计「同组中排序字段更小（或相等）的记录数」。
比如按部门分组、按薪资降序排，第 1 名就是该部门里薪资 ≥ 当前行薪资的人数：
SELECT dept, name, salary,
(SELECT COUNT(*)
FROM employees e2
WHERE e2.dept = e1.dept
AND e2.salary >= e1.salary) AS rank
FROM employees e1;
注意这里用 >= 是为了处理并列（相同薪资算同一排名），若要严格连续排名（并列后跳号），改用 > + 1：
(SELECT COUNT(*) + 1 FROM employees e2 WHERE e2.dept = e1.dept AND e2.salary > e1.salary) AS rank
为什么不能直接在 ORDER BY 里嵌套标量子查询
多数数据库（如 MySQL 5.7、PostgreSQL、SQL Server）明确禁止在 ORDER BY 子句中使用含外部引用的标量子查询，会报错 Invalid use of subquery 或类似提示。因为排序阶段无法稳定关联外层行上下文。
可行替代方案只有两个：
- 把标量子查询放到 SELECT 列表中计算排名，再用外层查询对这个别名列排序
- 改用窗口函数（如果环境允许），
ROW_NUMBER() OVER (PARTITION BY dept ORDER BY salary DESC)更安全高效
性能差到什么程度？什么时候必须换方案
标量子查询实现分组排名是典型的 O(n²) 操作：每行都要扫描一次全表（或本组数据）。1 万行员工数据，实际执行可能触发上亿次比较。
以下情况必须放弃标量子查询：
- 表行数 > 5000，且分组数 > 100
- 需要实时响应（如 Web 接口），延迟超过 500ms
- 数据库版本支持窗口函数（MySQL 8.0+、PostgreSQL 8.4+、SQL Server 2005+），却还在手写子查询
哪怕只是临时查数，也建议先加复合索引：CREATE INDEX idx_dept_salary ON employees(dept, salary DESC);，否则子查询几乎必走全表扫描。
GROUP BY 和标量子查询能一起用吗
不能。标量子查询依赖逐行计算，而 GROUP BY 会折叠行；一旦用了 GROUP BY，外层就只剩聚合结果，子查询里的 e1.dept 可能变成非确定值（尤其 MySQL 5.7 的 SQL_MODE 允许时），导致排名错乱甚至报错 Unknown column 'e1.dept' in field list。
正确做法始终是：子查询内部完成分组逻辑（靠 WHERE e2.dept = e1.dept），外层不做 GROUP BY。真要聚合排名结果（比如“每个部门前 3 名人数”），必须两层嵌套：
SELECT dept, COUNT(*) cnt
FROM (
SELECT dept, name,
(SELECT COUNT(*) + 1 FROM employees e2
WHERE e2.dept = e1.dept AND e2.salary > e1.salary) rnk
FROM employees e1
) t
WHERE rnk <= 3
GROUP BY dept;
嵌套层级一多，可读性和维护性就迅速下滑——这恰恰是标量子查询做排名最隐蔽的代价。
