软考下午题SQL数据查询全攻略：从语法骨架到多表连接与分组统计
1. 软考下午题里的SQL数据查询，到底考什么
如果你是正在备考软件设计师中级的朋友，那你一定知道，下午题第一题几乎年年都是数据库设计，而SQL数据查询就是这道题里最实在的那部分分。上午题当然也会冒出来几道SQL选择题，但真正拉开差距的，是下午题那道让你对着表结构写查询语句的大题。
我在当年备考软件设计师的时候，对SQL这一块态度经历了一个很有意思的转变：最开始觉得不就是几个SELECT语句吗，把表里的数据捞出来谁不会；后来才意识到，软考考的不是“你会不会写SQL”，而是“你在给定表结构和需求描述的前提下，能不能用最标准的语法把答案写对、写全、写严谨”。很多考生在这儿丢分，并不是因为不会SQL，而是因为不熟悉软考的评分逻辑和考察角度。
这篇文章，我就把软件设计师考点里SQL数据查询相关的所有重难点掰开揉碎。从基础语法到多表连接，从聚合分组到子查询嵌套，再附上软考实战中的高频坑和我的解题套路。无论你是第一次接触SQL，还是已经写过不少但想摸清软考路子，这篇都能帮你在考场上多拿几分。
2. SQL查询的地基：SELECT语法骨架与执行顺序
2.1 一个完整的SELECT可以有这么多子句
先来建立整体感。SQL数据查询的核心就是SELECT语句，但一个完整的SELECT远不止“选列”这么简单。在软考里，题目经常要求你写的查询可能会用到下面这些子句的全部或一部分：
很多考生背得出这个模板，但一到具体题目就乱套，根本原因是没有把每个子句的职责搞清楚。我们来逐一拆解：SELECT负责选出你想要显示出来的列；FROM指定数据来自哪张表；WHERE在分组之前对每一行数据进行筛选；GROUP BY把经过WHERE过滤之后的行按指定列分组；HAVING对分组后的结果做筛选；ORDER BY对最终结果排序。
我在培训班带新手的时候，最喜欢用生活场景打比方：你逛超市想统计“每个品牌在周三之后卖了多少件且库存少于100的商品”，FROM是走进超市，WHERE是只留下周三之后的销售记录，GROUP BY是把这些记录按品牌归堆，HAVING是从这些堆里挑出总件数满足条件（库存少于100）的品牌，SELECT是你最后只看品牌名和件数这两个信息。这样一拆解，每个子句干什么就清楚了。
2.2 执行顺序比书写顺序更重要
这里有一个很多考生到考前都会搞混的点：SQL的书写顺序和执行顺序并不一样。你别看SELECT写在最前面，数据库引擎实际执行的时候，它反而是后面才处理的。完整的逻辑执行顺序是这样：
FROM：确定数据源WHERE：对源数据做行级过滤GROUP BY：对过滤后的数据分组HAVING：对分组做过滤SELECT：确定输出列，计算表达式ORDER BY：对结果排序
为什么搞懂这个顺序对考试这么重要？我举一个特别典型的例子。有同学写“查询商品表中库存大于100的每个分类的平均价格”，他可能是这么写的：
这个语句执行直接报错，因为WHERE在GROUP BY之前执行，AVG(价格)是分组之后才会产生的聚合结果，WHERE阶段根本算不出来。正确的做法是把“平均价格大于100”这个条件放到HAVING里：
每次做这类题，你在心里默念一下执行顺序，基本就能避免把HAVING误写在WHERE、把聚合条件放错位置这种低级错误。软考上午题也经常会出这种“下列SQL语句哪个能正确执行”的选择题，考的就是你对执行顺序的理解，而不是单纯让你背诵语法。
3. 基础过滤与排序：WHERE、DISTINCT、ORDER BY这些细节别送分
3.1 条件筛选时的运算符优先级陷阱
WHERE子句是软考SQL查询里出现频率最高的考点，没有之一。几乎每年下午题都会有一小问是“查询满足某某条件的记录”，看起来简单，但里面藏着不少细节。
首先是运算符的优先级问题。WHERE里可以用的运算符很多：比较运算符（=、>、>=、<、<=、<>）、逻辑运算符（AND、OR、NOT）、范围判断（BETWEEN AND）、集合判断（IN）、模糊匹配（LIKE）、空值判断（IS NULL）。它们的优先级从高到低大致是：比较运算符 > NOT > AND > OR。
因为这个优先级，很多同学写条件时容易在实际语义上犯错。看这个例子：
由于AND优先级高于OR，这个语句的实际含义变成了“部门编号为1的员工，或者部门编号为2且工资大于5000的员工”。要实现原意，必须用括号：
考场上，这种题一旦出现，很多考生当场看不出来问题，但评分标准就是这么严。我的建议是：只要WHERE里同时出现了OR和AND，先无条件加上括号，这样既保证语义正确，也给阅卷老师一个清晰的信号——你懂优先级。
3.2 LIKE模糊查询的匹配规则和考法
LIKE也是软考里特别爱考的一个点，尤其是通配符的用法。常见的有两个：%表示任意长度的任意字符（包括零个字符），_表示任意单个字符。
举个例子你就理解了。如果我们有一张学生表，要查询姓“张”的学生，写法是：
这里的%可以匹配“三”、“伟”、“晓明”任意一种情况。如果要查询姓“张”且名字只有两个字的学生，就要用_：
软考上午题经常用这种题来考通配符的辨析。你只要记住：%管“多长都行”，_管“必须有且只有一个”，就不会被绕进去。还要注意，中文环境下，一个_代表一个汉字，不要把它想象成字节宽度。
3.3 DISTINCT是去重，但很多人不知道它对NULL的处理
DISTINCT在软考中也是一个常考点。它的作用是去除结果集中完全重复的行。这里有一个容易被忽视的细节：如果查询的列含有多个NULL值，DISTINCT会把这些NULL行合并为一行，因为NULL = NULL在DISTINCT的语境中被视为相同。
我见过一道上午题，问“统计职工表中不同部门编号的数量”，答案应该是：
如果你写的是SELECT COUNT(部门编号) FROM 职工;，那统计的就是职工总人数（忽略NULL号），和题意完全两码事。软考很喜欢在这种地方设陷阱——考的语法不复杂，但就看你有没有真正理解这个函数搭配的含义。
排序方面，ORDER BY支持按一列或多列排序，ASC升序、DESC降序，默认是升序。这里有两个注意点：一是ORDER BY放在最后；二是多列排序时，是先按第一列排，再在第一列相同的基础上按第二列排。比如“按部门升序，同部门内按工资降序”，写法是ORDER BY 部门编号 ASC, 工资 DESC，顺序不能反。
4. 聚合函数与GROUP BY：软考下午题的“必做大菜”
4.1 聚合函数的使用边界和NULL的坑
聚合函数这类题在下午题里出现的概率极高，而且得分率往往不太理想。常见聚合函数有COUNT、SUM、AVG、MAX、MIN。每个函数的功能不难理解，但关键在于处理NULL值的行为。
COUNT(*)统计的是行数，不管某列是不是NULL；COUNT(列名)统计的是该列中非空值的个数。SUM和AVG会忽略NULL值，也就是只对非NULL的行进行计算。MAX和MIN同样忽略NULL。
举个例子，一张订单表里有三笔订单，金额分别是100、200、NULL。那么AVG(金额)的结果是150，而不是100。不少考生，包括当年的我，第一次遇到这种题时都想不到NULL会被直接跳过。软考上午题特别爱出这种数字类型的计算题，你得养成一种条件反射：一看到聚合函数，先想如果这列里有NULL，答案会怎么变。
4.2 GROUP BY分组查询的“完整语法容貌”
分组查询是SQL里最常考的综合题型。典型场景是“按某个维度统计”。比如：
查询每个部门的人数、平均工资和最高工资：
这里有个语法规则我要特别强调：当你使用了GROUP BY之后，SELECT列表中的非聚合列必须出现在GROUP BY子句中。比如上面这条语句，部门编号在GROUP BY里，所以能被单独放在SELECT里；但如果你还想在SELECT里放员工姓名，那就错了，因为每个分组可能有多个不同姓名，数据库不知道该显示哪一个。
软考下午题特别喜欢让你补全SELECT后面的句子，很多考生补着补着就多写了非分组列，结果整个语句不合法。我的习惯是，在动手写之前先把GROUP BY写在草稿上，然后回头检查SELECT里的每一个非聚合列，确保它们都在GROUP BY中出现过。
4.3 HAVING与WHERE的定位差异
HAVING和WHERE的区别，在前文提过一嘴，这里展开再多说几句，因为这是软考选择题里稳居前三的高频考点。
WHERE在分组前过滤行，HAVING在分组后过滤组。WHERE后面不能直接用聚合函数，HAVING可以。- 能用
WHERE过滤的条件，尽量用WHERE，因为先过滤掉行可以减少分组计算量。
看一个综合例题。有一张销售记录表sales，字段包括商品编号、销售日期、销售量。要查询“总销售量大于500的商品编号及总销售量”，并且只要2023年1月之后的数据。根据规则，日期条件用WHERE，总量条件用HAVING：
这道题如果把HAVING SUM(销售量) > 500换成WHERE SUM(销售量) > 500，立刻报错。软考下午题就喜欢用这种题目来检验你对两个子句定位的理解。你在平时练习时，可以做一个小训练：每次写带分组的SQL，先问自己“这个条件能不能在分组之前判断”，如果能，就放WHERE，不能，才放HAVING。
5. 多表连接查询：下午题里最能拉分的一块
5.1 内连接与等值连接的来龙去脉
软考下午题的数据库设计大题，通常会给你两个或三个表，然后让你根据需求查询跨表的数据。这就涉及连接查询。考纲里重点要求的是内连接（INNER JOIN，通常简写为JOIN）和外连接（LEFT JOIN、RIGHT JOIN），其中内连接是绝对的主角。
内连接的逻辑是：只返回两张表中满足连接条件的记录组合。软考里最常见的连接条件是等值连接，也就是用=把两个表的关联字段连起来。比如有两张表：学生(学号, 姓名, 班级编号)和班级(班级编号, 班级名称)。要查询每个学生的姓名以及他所在班级的名称，SQL可以写成：
这里有一个值得展开的点：旧式语法里用逗号分隔多表，然后在WHERE里写连接条件，比如：
两种写法语义等价。软考的部分真题参考答案里，两种写法都给分。但我的建议是你在答卷时使用JOIN ... ON的标准现代写法，因为它的表关系更清晰，也方便阅卷老师看懂你的思路。不过你也要能看懂旧写法，毕竟上午题的选择题可能用旧写法出题，你看不懂可不行。
5.2 外连接的LEFT JOIN和RIGHT JOIN怎么区分
外连接是很多考生觉得难啃的骨头。但你只要抓住一个核心思想：外连接返回的不仅是能匹配上的行，还会保留某张表的所有行，匹配不上就用NULL填充。
LEFT JOIN保留左表的全部行。RIGHT JOIN保留右表的全部行。软考下午题常考的是LEFT JOIN，典型场景是“查询所有学生的选课情况，没选课的学生也要显示出来，选课信息用NULL表示”。
打个比方。还是学生表和选课表，如果有一个学生没有选任何课程，内连接就会把他丢掉。但用左连接，所有学生都会保留：
这个查询结果里，没选课的学生，课程名称列会显示为NULL。
我在备考时遇到的实际问题是：分不清LEFT JOIN和RIGHT JOIN到底保留哪边的表。后来我给自己编了一个记忆口诀：LEFT保存左边人，RIGHT保存右边人，答题时先在草稿上画两个圆圈，标清左右，再把保留那侧全行的条件写上，基本不会错。
5.3 三表连接的写法与踩坑经历
下午题里，三张表连接的情况也不少见，比如学生、课程、选课三个表。这个时候，你要做的就是连续写两个JOIN。SQL允许这样写：
这里面的关键就是连接顺序和连接条件不能乱。你每连接一张表，都要明确“这张表拿什么字段和上一张结果集关联”。我当时第一次写三表连接，把学生和课程直接通过学号关联了，结果把结果集搞得乱七八糟，其实就是没有理解中间表（选课）起的是“桥”的作用。
三表连接的语法并不难，难的是你在考场上紧张的时候，能理清表之间的关联字段。我的建议是做题前先花30秒把三张表的字段关系写在草稿纸上，画个简单的连线图（人脑画，不用任何工具），再落笔写SQL，错误率会直线下降。
6. 子查询与集合操作：进阶考点，软考上午下午通吃
6.1 子查询的几种形态与书写位置
子查询说白了就是SQL里嵌套SQL。软考下午题，子查询的考法通常是“查询满足某种统计条件的结果”，比如“查询工资高于平均工资的员工姓名”。这道题你会本能地想用聚合函数，可条件是逐行判断的，不能直接写在WHERE里，怎么办？子查询就派上用场了：
这里的(SELECT AVG(工资) FROM 员工)就是子查询，它先算出全局平均工资，再让外层查询逐行比较。这种返回单个值的子查询叫“标量子查询”，是软考里最基础也最高频的类型。
除了放在WHERE里跟比较运算符配合，子查询还可以出现在FROM后面当作临时表，或者放在SELECT后面当作输出列。软考下午题偶尔会考到“将查询结果作为子查询再查一遍”，也就是FROM (SELECT ...)这种嵌套写法。遇到时，你只需要把子查询的结果当成一张“临时生成的表”，再用连接或过滤的逻辑去处理它即可。
6.2 IN与EXISTS的区别，考试到底该用哪个
子查询搭配IN和EXISTS在软考中经常成对出现。先说IN的用法：外层查询的某个字段值等于子查询结果中的任意一个值，就满足条件。
EXISTS则是另一种逻辑：它不关心子查询返回什么具体的值，只关心子查询“有没有返回至少一行”。如果有一行，就返回真值；一行都没有，返回假值。所以EXISTS后面的子查询，SELECT什么其实都不重要，写SELECT 1也可以。
从考试角度看，IN更直观，因为它的语义容易理解。但EXISTS在软考中也有出现，而且有时候用EXISTS表达起来更自然，比如“查询所有选修了'数据库原理'课程的学生姓名”，用EXISTS写：
这种写法注意一个细节：子查询里的S.学号引用了外层学生表的字段。这种和外部表有字段关联的子查询叫做“相关子查询”，它的特点是每一行外层数据都要去子查询里检查一次。软考下午题如果出现这类写法，评卷的时候比较宽松，只要你逻辑对就能得分。但从容答题的角度，我更推荐你用IN和JOIN能解决的场景就别硬套EXISTS，减少写错的风险。
6.3 UNION与UNION ALL：合并结果别忘去重陷阱
集合操作UNION在软考中不算高频，但一旦出现，就是考“去重”这个点。UNION会自动合并并去重两个查询结果中完全相同的行；UNION ALL则简单地拼接所有行，不去重。
举例说明。要查询“研发部所有员工”和“工资大于8000的员工”的并集，如果一个人同时满足两个条件，用UNION他只出现一次，用UNION ALL他会出两次。软考上午题最喜欢用这种题来问“两种写法的结果有什么不同”。你要记住的口诀是：UNION ALL比UNION快，但因为不去重，结果可能比预期多；如果题目明确要求去重，就删掉ALL。
使用UNION的另一个硬性要求是：各个查询的列数和数据类型必须兼容。比如第一个查询SELECT了两列，第二个查询也必须SELECT两列，不能一个查两列一个查三列。这个规在下午题如果考到，通常是用“请指出下面语句的错误”这种形式来考，你得把这个约束印在脑子里。
7. 实操演练：软考下午题SQL查询典型题目全解析
7.1 真题还原：一张选课系统的查询需求
为了让你把前面讲的知识点串起来，我照着软考下午题数据库大题的风格，给出一套模拟题，并演示我的完整答题过程。
假设数据库中有三张表：
student表：sno（学号）、sname（姓名）、sdept（系别）course表：cno（课程号）、cname（课程名）、credit（学分）sc表：sno（学号）、cno（课程号）、grade（成绩）
题目需求如下：
- 查询全体学生的学号、姓名和系别。
- 查询成绩大于90分的学生的学号。
- 查询选修了课程号为“C001”课程的学生姓名。
- 查询每个系选修了课程的学生人数。
- 查询所有学生的选课信息，包括没有选课的学生姓名。
7.2 逐题手写答案与解题思路
第1题是最简单的基础查询，没有任何过滤和连接，直接写：
第2题同样是一张表内的条件查询，成绩字段在sc表里，所以：
注意这里可能会有一个坑：如果一张sc表里同一个学生选了多门课且都大于90分，这个学生的学号会重复出现。如果题目要求“有哪些学生”，最好用DISTINCT：
第3题要跨两张表查询学生姓名，因为student表没有课程号，course表没有学号，关联的桥梁是sc表。这就是典型的三表连接。写法如下：
第4题的关键词是“每个系”和“人数”，看到“每个”，马上想到分组。JOIN之后按系别分组，再用COUNT统计人数。注意“选修了课程的学生”，说明需要用sc表作为关联表，否则一个学生如果一门课都没选，他所在的系也会被统计为一个人，这就不符合题意了。所以先JOIN再分组：
第5题“所有学生的选课信息，包括没有选课的学生”，这是典型的左外连接场景。student表在左，sc表在右，用LEFT JOIN：
这五道题如果一口气做下来，你会发现它们背后其实对应了我前面讲的五大能力：基础查询、条件过滤、多表连接、分组统计、外连接。软考下午题本质上就是把这几件事组合起来考你，没有哪一步是超纲的。
7.3 拿分技巧：答题时的顺序和时间管理
在考场上，我建议你把SQL查询题放在你最有把握的时段优先做。下午题总分75分，合格线通常是45分，时间分配上，数据库大题的15分你最迟要在25分钟内拿下来。具体策略是：先把题目里所有需求通读一遍，标出“筛选”“分组”“连接”“去重”等关键词，再动手写。不要上来就写，因为软考的SQL题往往是一环扣一环，上一问的结果可能就是下一问的输入，前面想错了，后面全歪。
此外，写SQL时要注意列名前面加表名或表别名。比如SELECT student.sname而不是SELECT sname，在单表查询中不加没问题，但多表连接时如果不加前缀，万一两个表有同名字段，数据库会报错。软考阅卷时对这种细节一般不会太苛刻，但写清楚了能避免你复查时自己也看不出错来。
8. 高频易错点与考前自测
8.1 六个容易丢分的细节，逐条对照自检
下面这六条是我复盘了历年真题和自己踩坑经历之后总结出来的高频丢分点。你考前可以拿它做一次自查，只要这六条你都能说清原理，SQL查询这块就没大问题。
第一条：WHERE和HAVING搞混。 记住执行顺序，WHERE先行后组，HAVING先组后行。
第二条：COUNT(*)和COUNT(列名)混淆。 一个统计所有行，一个统计非NULL行。
第三条：使用GROUP BY时，SELECT里的非聚合列不在GROUP BY中。 这是语法错误，一查一个准。
第四条：多表连接时漏掉连接条件。 如果两张表直接FROM student, sc而忘记WHERE student.sno = sc.sno，得到的是笛卡尔积，结果数量会爆炸。上午题经常拿这个考你结果行数。
第五条：外连接的方向选反。 分清要“保留哪张表的全部行”。带LEFT JOIN时，保留左表，漏掉右边匹配不到的行用NULL填充。
第六条：LIKE中%和_用错。 %长、_短，不能混。
我备考那阵子，把这几条抄在便利贴上贴在电脑前，每次做SQL题之前先扫一眼，正确率确实稳定了很多。
8.2 答题时的排查顺序模板
如果你在考场上一道SQL题怎么想都想不明白，我强烈建议你按这个顺序排查：
- 确认需求里的动词是“查询、统计、列出”还是“更新、删除、插入”，先判断用的语句类型。
- 如果是查询，画表关系草稿，看是否需要连接、连接几张表。
- 圈出需求里的筛选条件，判断这个条件是在分组前能用
WHERE，还是只能分完组再用HAVING。 - 看到“每个”“各自”“按”之类的字眼，优先想到
GROUP BY。 - 看到“所有……包括没有……”的字样，优先想到
LEFT JOIN或RIGHT JOIN。 - 最后检查
SELECT输出的列名和题目要求是否逐一对应，有没有多写、少写。
这六步走下来，你自己就能发现大多数问题所在。软考SQL题没有那种完全偏门的，所有答案都藏在题干里，你要做的就是一层一层把条件梳理出来，然后用标准语法写出来。
8.3 窗口函数要不要学？
你可能会看到相关热词里有“SQL窗口函数”，那软考要不要学？我的答案是：了解即可，不必深挖。当前软考大纲和真题对窗口函数的直接考察极少，上午题偶尔会出现在一个选项里让你识别，下午题更是几乎不会要求你用ROW_NUMBER()这类函数解题。所以如果你备考时间紧张，集中精力把我前面讲的这些基础查询、连接、分组、子查询吃透就足够了。等考完试，如果你想在实际工作中做数据分析，再回头补窗口函数也不迟。
9. 我的实际备考感想
说起来，我在SQL查询上栽过的最大跟头就是多表连接时搞不清保留哪张表的全部行。后来我养成了一个习惯：每道连接查询题，都在草稿纸上把主表圈出来，再把“要保留的不匹配行”用虚线画一下，思路清晰了，答案自然也就不会写反。
另一点心得是，软考下午题的SQL查询，按点给分的倾向比较明显。你哪怕整体语句有点小瑕疵，只要关键的表连接关系、分组字段、过滤条件写对了，通常也能拿到绝大多数分数。所以考试时不要因为一个小错误慌了神，能写多少写多少，写全了总比空着强。
SQL数据查询是软件设计师考试里性价比很高的一块内容，语法固定、题型重复度高、规律明显。只要你把基础语法吃透，再把多表连接和分组统计这两块硬骨头啃下来，下午题这道15分的大题，你是有很大把握拿满分的。
191 364 1506 3174 973 1163 268 918 81 207 41