SQL子查询那些事儿，数据库操作其实没那么难，慢慢玩就懂了

说到SQL子查询,很多刚开始接触数据库的朋友可能会觉得头大，感觉这玩意儿很复杂，很高深，但其实啊，它就像我们平时说话聊天一样，只不过是把一句话套在另一句话里说，咱们今天就不讲那些让人犯困的专业术语，就用大白话聊聊子查询那些事儿，你会发现，数据库操作真的没那么难，慢慢玩着就懂了。

想象一下这个场景：你想找出公司里工资比张三高的所有员工，你的脑子是怎么思考的呢？你肯定会先想：“张三的工资是多少？” 知道了张三的工资，比如是8000块，你再想：“哪些人的工资大于8000块呢？” 这个思考过程，其实就是子查询的核心思想，我们把第一个问题“张三的工资是多少？”作为一个内部查询（也就是子查询），然后把它的结果（8000）交给第二个问题“工资大于多少？”这个外部查询来用，写成SQL的样子大概就是这样：

SELECT 姓名 FROM 员工表 WHERE 工资 > (SELECT 工资 FROM 员工表 WHERE 姓名 = ‘张三’);

看,是不是很直观？括号里的部分就是子查询，它先执行，查出张三的工资，然后外面的主查询再用这个结果去筛选出所有工资更高的员工，这就叫“子查询”，顾名思义，就是一个查询语句里又嵌套了另一个查询语句。

子查询可以放在很多地方,不只是跟在WHERE后面，它还可以放在SELECT后面，用来充当一个计算出来的列，举个例子，你想看看每个员工的信息，同时还想一眼看出他的工资比公司平均工资高多少或者低多少，这时候你就可以这么写：

SELECT 姓名, 工资, (SELECT AVG(工资) FROM 员工表) AS 公司平均工资, 工资 - (SELECT AVG(工资) FROM 员工表) AS 与平均工资的差距 FROM 员工表;

这里,我们用了两次相同的子查询来计算公司的平均工资，然后把它作为一个新的列显示出来，并且现场计算了差距，虽然这样写可能效率不是最高的（因为算了两次平均值），但理解起来很容易对吧？你先知道公司平均工资这个数，然后把它和每个人的工资摆在一起比较。

还有一种常见的情况,是子查询放在FROM后面，这时候，子查询的结果就像是临时生成的一张新表格，主查询再从这张临时表格里取数据，你想找出每个部门里工资最高的那个人，这个逻辑稍微复杂一点，可以先按部门分组，找出每个部门的最高工资，生成一个临时结果（我们姑且叫它“部门最高工资表”），然后拿着这个临时结果，再回到原始的员工表里去匹配，看哪个员工属于这个部门并且工资正好等于这个最高工资，SQL可以这么写：

SELECT a.部门, a.姓名, a.工资 FROM 员工表 a, (SELECT 部门, MAX(工资) AS 最高工资 FROM 员工表 GROUP BY 部门) b WHERE a.部门 = b.部门 AND a.工资 = b.最高工资;

这个例子看起来比前面两个要长一点,但拆开看也不难，括号里的子查询先跑，它干的事儿就是分组统计，得到了一个虚拟的“部门最高工资表”，里面有部门名和对应的最高工资，然后主查询就把原始的“员工表”和这个虚拟表连接起来，找出同时满足部门相同且工资等于该部门最高工资的记录。

子查询也有需要注意的地方,如果子查询返回的结果不止一个值，你就不能用普通的比较符号（>）了，得用IN、ANY、ALL这样的词，比如说，你想找出和市场部所有员工工资都相同的员工（这可能是个不太符合实际的例子，但为了说明问题），你就得用ALL关键字。

刚开始写子查询的时候,最容易犯的错可能就是括号没写对，或者子查询返回了太多列（通常子查询在比较时只能返回一列），别担心，这都很正常，多写几次，多报几次错，慢慢就熟练了。

子查询就是一个“分两步走”或者“问题套问题”的策略，当你遇到一个复杂的问题，一下子没法用一句简单的SQL说清楚时，就可以试试把它拆成几个小问题，先解决内部的小问题（子查询），再用小问题的答案去解决外部的大问题（主查询），数据库这东西，真的就像是个大玩具，你越是抱着玩的心态去尝试各种写法，看看不同的SQL会得出什么结果，你就越能摸清它的脾气，别怕出错，大胆地去写，去试，慢慢地，你就会发现，这些操作其实没那么难，还挺有意思的。