正确写法是用相关子查询统计同部门薪资严格高于当前员工的人数≤2，即WHERE (SELECT COUNT(*) FROM employees e2 WHERE e2.dept_id = e1.dept_id AND e2.salary > e1.salary)
相关子查询怎么写才能正确限制“每个部门前三名”
直接用 ORDER BY salary DESC LIMIT 3 在主查询里行不通——SQL标准不支持在非聚合查询中对分组结果用 LIMIT。必须靠相关子查询数出“比当前员工薪资高的人数 ≤ 2”，这才是可移植的核心逻辑。
关键不是排序，而是计数：对每条员工记录，查同部门里薪资严格大于它的员工有几个；≤2 就说明它是前三（允许并列，但不跳名次）。
- 子查询必须引用外部表的字段，比如
e1.dept_id和e1.salary，否则就变成普通子查询，失去“相关性” - 比较条件用
>而不是>=，避免把自身算进去 - 注意 NULL 安全：如果
salary可能为空，加WHERE salary IS NOT NULL防止计数异常
MySQL 8.0+ 用窗口函数更稳，但老版本只能靠相关子查询
如果你用的是 MySQL 8.0、PostgreSQL 或 SQL Server，ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY salary DESC) 是更清晰、性能更好的选择。但很多生产环境还在跑 MySQL 5.7 或 MariaDB 10.3，这时相关子查询是唯一兼容方案。
相关子查询在大数据量下会明显变慢（O(n²)），但胜在语义直白、无需临时表或变量。
- 测试时先加索引：
CREATE INDEX idx_dept_salary ON employees(dept_id, salary DESC); - 避免在子查询里 SELECT *，只 COUNT(1)，减少数据搬运
- 如果部门人数极少（如平均＜5人），性能差异几乎不可感知
容易漏掉的并列处理：TOP 3 不等于 ROW_NUMBER ≤ 3
“前三名”在业务中常指“薪资最高的三档”，而非严格三条记录。比如部门里有 5 人薪资为 [15k, 15k, 14k, 13k, 13k]，按并列规则应返回前 4 条（两个 15k 算第1名，14k 是第2名，两个 13k 是第3名）；但用 ROW_NUMBER() 会截断为 3 条。
相关子查询天然支持这种语义，只要把计数逻辑改成“薪资 ≥ 当前值的人数 ≤ 3”即可：
WHERE (
SELECT COUNT(*)
FROM employees e2
WHERE e2.dept_id = e1.dept_id
AND e2.salary >= e1.salary
) <= 3- 用
>=替换>，实现并列不降档 - 此时结果可能超过 3 行/部门，但符合业务常说的“前三名”含义
- 若需严格 3 行且支持并列（即 DENSE_RANK），相关子查询就力不从心了，得换窗口函数
字段别名和去重：为什么 SELECT * 常导致错误
相关子查询本身不产生新列，但主查询若用 SELECT *，可能因子查询里用了相同别名引发歧义，尤其当表有同名字段（如 id 在 employees 和 departments 中都存在）。
- 显式列出字段：
SELECT e1.id, e1.name, e1.salary, e1.dept_id - 所有字段加表别名，避免
Column 'id' in field list is ambiguous - 如果要连部门名，JOIN 写在主查询，别塞进子查询里——子查询只负责过滤，不负责扩展字段
真正卡住人的往往不是语法，而是没想清楚“前三”到底指什么：是严格三条记录？还是并列后最多三条薪资档位？前者用 > 计数，后者用 >=，差一个符号，结果可能翻倍。
