1. 这道经典SQL题，到底在考什么
很多人学SQL时遇到的第一道坎，往往就是“SQL 181：超过经理收入的员工”。这道题表面上看就是一个简单的查询，实际上它把SQL里最核心的几个概念全揉在了一起：自连接、JOIN语法、别名机制、还有对“行与行关系”的理解。我带了这么多年的新人，几乎每次都要用这道题来检验对方是不是真的理解了SQL的思维，而不只是会背几条SELECT语句。
题面的需求很简单：有一张员工表Employee，包含id、name、salary和managerId四个字段，managerId指向该员工的直属经理的id。要求找出所有收入超过自己经理的员工姓名。听起来就是一句话的事，但真正动起手来，你会发现一个很有意思的问题：你要比较的数据不在不同行之间，而是在同一张表的“上下级”两行之间。
很多人第一反应是：那是不是要复制两张表？其实方向对了，但不知道具体怎么操作。这道题最核心的考点，就是你能不能想到用自连接，或者退一步用子查询，把一张表当成两张表来用。而自连接这个操作，恰恰是SQL新手最容易卡住的地方。因为平时写JOIN都是连接两张不同的表，很少遇到“自己连自己”的场景。
从实际应用的角度来说，这道题解决的是一种非常普遍的需求模式：同一张业务表内部存在层级或关联关系，需要跨行进行比较或计算。比如组织架构里对比员工和经理的薪资、订单表里对比同一客户不同时间下的订单金额、商品表里比较同品牌下不同型号的价格。只要做过几年数据开发或分析，这种需求几乎每周都能碰上。
所以这道题适合谁？我觉得不只是面试前临时抱佛脚的求职者，任何想把SQL写明白的人都值得花点时间把它吃透。因为一旦理解了自连接背后的逻辑，后面再遇到更复杂的表间关联、树形结构查询、甚至某些窗口函数的使用场景，都会轻松很多。
2. 拆解题目本质：单表内部如何实现上下级比较
2.1 数据模型和表结构分析
先看题目给的表结构。Employee表通常长这样：
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | int | 员工唯一标识，主键 |
| name | varchar | 员工姓名 |
| salary | int | 员工薪资 |
| managerId | int | 经理的id，关联本表的id字段 |
需要注意的是，managerId是自引用外键，它指向的是同一张表里的id。也就是说，这张表既存了员工信息，也存了经理信息，经理本身也是员工。只有CEO这种级别的员工，managerId可能为NULL。
我实际操作的时候习惯先把表建好，插入几行有代表性的数据，再开始写查询。比如我常用的测试数据是这样：
CREATE TABLE Employee ( id INT PRIMARY KEY, name VARCHAR(100), salary INT, managerId INT ); INSERT INTO Employee (id, name, salary, managerId) VALUES (1, 'Joe', 70000, 3), (2, 'Henry', 80000, 4), (3, 'Sam', 60000, NULL), (4, 'Max', 90000, NULL);这里Joe的经理是id=3的Sam，Joe的薪资70000比经理Sam的60000高，所以Joe应该出现在结果中。Henry的经理是Max，Henry薪资80000低于Max的90000，所以不出现在结果中。这是这道题的标准测试数据，能把逻辑测清楚。
2.2 为什么需要自连接：跨行比较的SQL思维
SQL是一个基于集合的操作语言，它的难点在于：你习惯用excel思维去看待数据，一行一行地去比对，但SQL不是这么工作的。SQL里要比较两行数据，就必须把两行数据“放到同一行”里，然后用WHERE条件去做筛选。
这道题里，员工和经理的信息都在同一张表里，但它们是不同的行。而我们要做的比较，恰恰是员工行和经理行之间的薪资比较。这就逼着你必须创造一种方式，让一张表以两种身份同时出现在FROM子句里。于是就有了自连接。
自连接的写法其实就是给同一张表起不同的别名，然后把它当成两张独立的表来JOIN。这个“当成两张表”的理解特别重要。我每次给新人讲的时候都会强调一个类比：你可以把自连接理解为把一张表复制了一份，一份叫员工表A，一份叫经理表B，然后通过A.managerId = B.id这个条件，把每个员工对应的经理行“挂”到同一行上。虽然物理上只有一张表，但在SQL的执行逻辑里，它完全等价于两张表做关联。
这种“A表的某个字段等于B表的主键”的连接方式，恰恰反映出managerId作为外键存在的基本逻辑。而外键关联在SQL里的实现手段，就是JOIN。
2.3 从执行逻辑看JOIN的底层行为
JOIN的底层逻辑其实是一个笛卡尔积，然后按ON条件筛选。换句话说，MySQL先内存里把Employee表当作A、B两个集合，做一次交叉组合，比如表里有4条记录，交叉后就有4×4=16条组合，然后通过A.managerId = B.id这个条件，过滤掉那些没有意义的组合，剩下的每一行就是“员工-经理”的配对。
理解了这一步，你就会明白为什么写自连接时ON条件这么关键。如果漏写了ON条件或写错了字段，结果可能就是16行乱配，或者干脆什么都没匹配出来。在实操中我还经常看到有人把ON条件写反，写成A.id = B.managerId，导致结果完全反了。
所以这道题看上去只是返回一个name字段，但它能帮你把JOIN的执行原理、ON条件的含义、别名的必要性全部串起来。这也是它成为经典SQL题的原因。它不是一个偏题怪题，而是一个高度浓缩了SQL核心概念的入门必刷题。
3. 三种主流的SQL解法：不只是写出来，要理解为什么
3.1 解法一：自连接两表JOIN，最直接的思路
第一种解法是最容易理解的，直接让员工表和经理表做一次自连接：
SELECT a.name AS Employee FROM Employee a JOIN Employee b ON a.managerId = b.id WHERE a.salary > b.salary;这段SQL的执行逻辑是这样的：a是我们关注的员工，b是该员工对应的经理；JOIN条件a.managerId = b.id把每个员工挂到他的经理行上；WHERE子句再过滤掉那些工资不超过经理的员工。
这里有一个新手很容易踩的坑：漏掉WHERE条件。如果你只写了JOIN，没有加薪资比较，那么返回的是所有有经理的员工，不管他工资比经理高还是低。虽然这道题的输出结果不同，但逻辑上就错了。我见过不少人在OJ上提交时答案不对，排查到最后发现WHERE条件没写，或者写错成了a.salary > b.salary，结果把条件挂在ON后面。ON和WHERE虽然有时结果一样，但语义不一样，JOIN的ON负责连接逻辑，WHERE负责结果过滤。
另外一个细节就是SELECT后面的a.name AS Employee。这里有个小坑：题目要求返回的列名是Employee。而Employee又是表名，容易造成混淆。不过SQL标准允许列名和表名重名，所以写法没问题。但为了可读性，我建议用别名来区分，比如把返回列命名为Employee，表示“符合条件的员工姓名”。
3.2 解法二：子查询方式，比较适合刚接触SQL的人
第二种方式是子查询。它的核心思路是：先查出每个员工的经理薪资，然后再做比较。可以用相关子查询，也可以先把经理工资算成一张子表再关联。
写法一：相关子查询，直接在SELECT里查经理的工资：
SELECT a.name AS Employee FROM Employee a WHERE a.salary > ( SELECT salary FROM Employee b WHERE b.id = a.managerId );这里每次处理一行a的时候，都要去执行一遍子查询，找出a的经理工资。相关的意思是，子查询里引用了外层查询的字段a.managerId，两者产生了关联。
写法二：非相关的子查询，先构建一个经理工资映射表：
SELECT a.name AS Employee FROM Employee a JOIN ( SELECT id, salary FROM Employee ) b ON a.managerId = b.id WHERE a.salary > b.salary;从执行效率上说，写法二往往更好，因为子查询只执行一次，生成一张临时表，然后像普通表一样参与JOIN。而写法一每条员工记录都要执行一次子查询，对于大表来说性能压力会很大。我在实际生产环境里，几乎不会大规模使用相关子查询来做这种关联比较，除非表特别小。
但话又说回来，写子查询比写自连接更贴近自然语言。很多刚接触SQL的人反而更容易理解子查询方式，因为它就像先“查出经理的工资”，再去“比较员工的工资”，逻辑是递进式的。所以如果你面试时紧张，一下子忘了JOIN怎么写，先写出子查询方式稳住局面，也是OK的。
3.3 解法三：窗口函数写法，开拓视野
窗口函数在MySQL 8.0及以上版本、SQL Server、Oracle里都支持。虽然181这道题用窗口函数有些“杀鸡用牛刀”，但它能帮你打开思路。用窗口函数怎么解呢？
关键是把经理的工资“拉”到员工那一行上，这个操作叫平移。思路其实很清晰：
SELECT name AS Employee FROM ( SELECT name, salary, managerId, FIRST_VALUE(salary) OVER (PARTITION BY managerId) AS manager_salary FROM Employee ) t WHERE manager_salary IS NOT NULL AND salary > manager_salary;这里PARTITION BY managerId，意思是对每个经理管辖的员工分组，然后取该组内第一个salary值，也就是经理的工资。因为每个组内所有员工的managerId都一样，所以FIRST_VALUE取到的就是经理的工资。最后再用WHERE条件过滤。
这种方法虽然也能得到正确结果，但它本质上是在变花样地做“按组取数”，逻辑上比自连接绕一些。不过如果你在学窗口函数，拿这道题练练手还是挺有意思的。尤其当你要处理的场景变成了“取每个部门里工资最高的员工”这种问题时，窗口函数就成了正解。
三种写法对比一下：
| 写法 | 核心思想 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|
| 自连接JOIN | 同一张表用两个别名关联 | 逻辑清晰、执行高效 | JOIN条件需理解，新手易错 | 面试、生产环境首选 |
| 子查询 | 先查经理工资再比较 | 思路直观，贴近自然语言 | 相关子查询性能较差 | 小表或学习理解 |
| 窗口函数 | 组内平移经理工资 | 可扩展性强，适合更复杂需求 | 语法较复杂，有版本要求 | MySQL 8+、数据分析场景 |
4. 实操过程：从建表到验证的完整演示
4.1 建表和初始化数据的完整脚本
我建议你动手实践时，不要直接在OJ的编辑器里写，而是自己本地装一个MySQL或者SQL Server，建库建表，把整个流程走一遍。这样你对数据的感知会更清晰，遇到问题也更容易排查。我用的初始化脚本如下：
-- 创建数据库（如果不存在） CREATE DATABASE IF NOT EXISTS sql_practice; USE sql_practice; -- 创建员工表 CREATE TABLE Employee ( id INT NOT NULL, name VARCHAR(100) NOT NULL, salary INT NOT NULL, managerId INT NULL, PRIMARY KEY (id) ); -- 插入测试数据 INSERT INTO Employee (id, name, salary, managerId) VALUES (1, 'Joe', 70000, 3), (2, 'Henry', 80000, 4), (3, 'Sam', 60000, NULL), (4, 'Max', 90000, NULL);注意managerId字段我设成了NULL允许，因为经理可能没有上级，比如Sam和Max，他们的managerId是NULL。这在真实业务里非常常见，一个公司的顶层领导没有上级。
插入完数据，可以先用SELECT * FROM Employee看一下全貌，确认数据无误：
| id | name | salary | managerId |
|---|---|---|---|
| 1 | Joe | 70000 | 3 |
| 2 | Henry | 80000 | 4 |
| 3 | Sam | 60000 | NULL |
| 4 | Max | 90000 | NULL |
4.2 执行自连接查询并解释结果
现在执行自连接查询：
SELECT a.name AS Employee FROM Employee a JOIN Employee b ON a.managerId = b.id WHERE a.salary > b.salary;先看JOIN部分：a表是员工，b表是经理。执行连接后，中间结果是这样的：
| a.name | a.salary | a.managerId | b.id | b.name | b.salary |
|---|---|---|---|---|---|
| Joe | 70000 | 3 | 3 | Sam | 60000 |
| Henry | 80000 | 4 | 4 | Max | 90000 |
Sam和Max因为managerId是NULL，无法匹配到任何经理，所以被JOIN自然排除在外了。WHERE条件a.salary > b.salary，把Henry排除，因为80000不大于90000，最终只留下Joe。
符合条件的员工是：Joe。
4.3 数据扩展与边界情况验证
光有标准测试数据还不够，我建议你再加上一些边界情况来验证自己的查询是否健壮。比如：
INSERT INTO Employee (id, name, salary, managerId) VALUES (5, 'Alice', 85000, 1), (6, 'Bob', 75000, 1), (7, 'Tom', 120000, 2);这里Alice和Bob的经理都是Joe，Tom的经理是Henry。加上这些数据后，结果会怎么样？Alice的工资85000大于经理Joe的70000，所以Alice应该出现在结果里；Bob的工资75000也大于70000，所以也要出现；Tom工资120000大于Henry的80000，所以也要出现。
最终结果变成了Joe、Alice、Bob、Tom四个人。换句话说，只要员工的工资高于其直接经理，就满足条件，不区分员工和经理的职级差异。这个逻辑在真实业务中很常见，比如销售提成超过上级的案例比比皆是。
我还喜欢测试一种情况：如果两个人的工资一样，查询不应该返回任何人。数据上就是不要插入工资相同的记录，或者把某条记录的工资改掉再测一遍。这些边界测试能让你确信WHERE条件是严格的大于，而不是大于等于。
5. 常见问题与排查技巧实录
5.1 新手最容易犯的五个错误
这道题我在面试和带新人的时候，见过太多共性错误。整理成排查表供你对照：
| 错误现象 | 可能原因 | 解决办法 |
|---|---|---|
| 查询结果为空 | JOIN条件写反，把a.id = b.managerId写成了a.managerId = b.id的反向 | 检查ON条件的逻辑方向 |
| 返回所有员工 | WHERE条件没写，或写成了ON里 | 确认薪资比较写在WHERE里 |
| 报错：Unknown Column | 没加表别名，直接写了name、salary等字段，导致歧义 | 所有字段都加前缀a.或b. |
| 结果多出重复行 | 表里有重复记录，或JOIN时一对多匹配 | 检查数据唯一性，必要时用DISTINCT |
| 执行速度极慢 | 相关子查询在循环执行 | 改成JOIN或非相关子查询 |
这五个错误里，最常见的还是别名问题。尤其是在SELECT和WHERE里，如果不带别名前缀，多表JOIN时数据库分不清字段属于哪张表，直接抛错。记住一个原则：只要SQL里出现了两个表（哪怕出自同一张物理表），所有字段尽量都带上别名前缀，这个习惯能帮你规避掉一大半低级报错。
5.2 关于NULL值的处理
managerId为NULL的情况必须考虑。在自连接里，managerId为NULL的员工无法和任何经理行匹配，JOIN直接排除。但如果有人用了LEFT JOIN，情况就不一样了：
SELECT a.name AS Employee FROM Employee a LEFT JOIN Employee b ON a.managerId = b.id WHERE a.salary > b.salary;LEFT JOIN会把a表所有记录都保留下来,包括managerId为NULL的员工。但这些员工的b.salary是NULL，而NULL > 任何值都不成立，所以这些记录依然不会出现在最终结果里。结果和INNER JOIN一致。
但你如果换一种写法，把WHERE条件改为WHERE a.salary > COALESCE(b.salary, 0)，那么没有经理的员工也会因为工资大于0而全部出现在结果里，这显然不符合题目要求。所以这道题用INNER JOIN最稳妥，别搞LEFT JOIN，否则你还要额外处理NULL逻辑。
5.3 面试官除了看答案，还在看什么
这道题是SQL 181，属于一个入门难度题。但面试官绝不只是想看你能写出来，他们更看重这几点：第一，能不能主动说出多表关联时为什么要用别名；第二，知不知道ON条件和WHERE条件的区别；第三，面试官追问“如果数据量到百万级，哪种写法更快”时，能不能接住。所以你在准备时，不光要背答案，还要把每种写法背后的执行逻辑想清楚。
我自己面试时，如果候选人能主动提到“自连接的本质是一张表以两种角色参与JOIN”，或者能说出“相关子查询在大数据量下有性能隐患”，基本上这道题就算过了。
6. 从181到实战：同类型业务场景的举一反三
6.1 五类常见业务的同构需求
这道题的价值不在于题目本身，而在于它提炼出了一种需求模式：同一张表内的跨行比较。这种模式在真实业务里到处都是。
比如电商订单表，比较每个客户最近两笔订单金额的变化，看是涨了还是跌了。订单表里同一个用户有多行订单，你要把同一用户的不同订单行放在一行进行比较。这就是自连接加分组排序的操作。
再比如组织架构表，查询所有“下属工资高于上级”的异常数据。这和181题几乎一模一样，只是把员工表换成了组织架构表。我实际帮一家零售公司排查薪酬倒挂问题时，用的就是这个思路。
还有产品配置表里，同一类产品的不同型号参数做比较；数据库日志表里，同一台服务器前后两条记录的CPU使用率变化；甚至日活报表里，同一天不同渠道的数据做对比。这些场景的核心逻辑，都是“同表跨行比较”，掌握了181这道题的基础，这些需求都能套用同一套思路。
6.2 自连接的性能优化建议和替代方案
在实际生产环境里，如果表数据量很大，自连接可能会导致严重的性能瓶颈。因为自连接就是一次全表关联，如果两个关联列上没有索引，代价会很大。优化思路主要有三条：
第一，确保关联字段有索引。在Employee表上，managerId字段最好建索引，因为JOIN条件就是A.managerId = B.id，B.id是主键已经有索引了，但A.managerId往往没有。建立索引的SQL如下：
CREATE INDEX idx_manager_id ON Employee(managerId);第二，从写法上避免笛卡尔积。自连接本身就需要笛卡尔积，但ON条件能尽快过滤，所以ON条件里的字段选择非常关键。
第三，考虑用窗口函数替代。窗口函数不需要显式JOIN，在部分数据库引擎里的执行路径比自连接更优化。比如MySQL 8.0以上版本，在处理“同组内比较”这类需求时，窗口函数的性能往往不输自连接，而且写法上也更符合分析场景的直觉。
6.3 扩展思考：如何从“会做题”到“会建模”
最后说点个人体会。这道题的价值不仅在于SQL语法，它还在训练你的数据建模意识。当你在建表时设计了自引用外键（managerId），就已经默认了表内存在层级关系。而后续所有的查询，都要围绕这种关系的本质展开——要么JOIN，要么子查询，要么窗口函数。
很多人在学SQL时喜欢刷题，刷了好几页却感觉没进步。我自己的经验是，每做完一道题，要多问自己几个问题：这个查询解决的是什么业务问题？还有没有别的写法？如果数据量扩大100倍，当前写法还可行吗？把一个普通题目剥开揉碎，比走马观花过十道题更有效。
SQL 181这道题虽然简单，但如果能把自连接、别名、JOIN顺序、子查询性能这些点都理清楚，你的SQL基础就算是真的站稳了。以后碰到再复杂的表关联需求，你回头看这道题，会觉得它是一个特别好的起点。
