简介经典SQL面试笔试题详解PDF面向数据库入门学习者、求职备考者及程序员技能自查群体。资源汇总多道高频笔试真题内容覆盖分组聚合、ORDER BY排序、TOP限制、多表JOIN连接、子查询、外键关联等核心SQL语法每题附可直接运行的规范标准答案部分题目同时给出JOIN与WHERE两种等价写法便于对比掌握不同解题思路。具体题目包括按部门统计平均工资并排除指定部门、不使用MIN函数求最小值、跨Customer与Order表统计每位客户收入总和、从performance表筛选最高分记录、统计选修课程人数及成绩最高学生、每科大于90分人数统计、emp表部门最高与最低工资查询等由浅入深、覆盖面广适合笔试前集中复习与查漏补缺。资源为单文件PDF压缩包大小1.38MB轻量便携便于移动端随时翻阅。目前已有190人下载学习可用于数据库笔试前的快速刷题也可对照标准答案自查SQL基本功提升笔试通过率。1. SQL笔试题库值不值得刷先搞清这份资料到底能给你什么SQL数据库笔试题这东西平时翻着觉得简单真坐进面试教室却容易卡壳。我拿到这份文档时第一反应是当废纸处理翻了几页才发现它是一份能直接拿来复盘的SQL笔试题目合集——分组聚合、自连接、相关子查询、TOP排序、JOIN写法这些高频考点全都有而且不少题目还附了参考SQL和建表语句。文件名里的“编辑面试题”容易让人误会实际内容是数据库笔试和面试题与文字编辑没有关系。这份资源适合两类人一类是马上要面数据库岗的开发者拿来做最后两三天的题感突击另一类是带新人的组长可以把它当入职后的SQL摸底测试。题目大多围绕emp/dept、customer/order、student/course/score这类经典表结构展开不算复杂但考点集中每道题都能往深处追问一层。需要提醒的是少数答案存在笔误和旧语法比如把Revenue拼成revener、用了SQL Server 2005以后已经淘汰的*外连接写法。我的建议是把它当草稿而不是当标准答案每道题都放到真实数据库里跑一遍。下面我从分组聚合开始把这份题库里最有代表性的几组题拆开讲最后给出可复现的建库验证方法。2. 分组聚合从部门平均工资到“每科90分人数”的三道变式这份文档里有一大半题目在折腾工资和人数统计核心都是GROUP BY加聚合函数。单独看每道题都不难但面试官喜欢在分组条件、过滤时机、非聚合列上挖坑所以这部分值得仔细过。2.1 部门平均工资SQL执行顺序决定你该怎么写文档里第28题很典型抽出部门、平均工资要求按部门的字符串顺序排序不能含有humanresource部门。参考写法如下-- 题28按部门分组统计平均工资排除指定部门 SELECT depart_name, AVG(wage) AS avg_wage FROM employee WHERE depart_name human resource GROUP BY depart_name ORDER BY depart_name;这段SQL的关键不在AVG怎么写而在于SQL的执行顺序FROM先定位表WHERE先过滤掉human resource部门GROUP BY再按depart_name分组SELECT里计算每组平均工资最后ORDER BY对分组结果做字符排序。很多人习惯按书写顺序理解SQL把ORDER BY当成第一步真排查问题时就会绕圈子。这里有两个容易忽略的参数细节。第一AVG函数会忽略NULL值如果wage列有空值平均工资是按非空行算的题目没说明wage是否允许NULL面试时最好主动问一句。第二按字符串排序和按数值排序不一样ORDER BY depart_name走的是字符序在SQL Server默认排序规则下是拼音序而不是部门编号的数字序如果题目要求“按部门编号的字符串顺序”就写ORDER BY depart_id而不是depart_name。另外原题答案写的是depart_name human resource用不等于排除单个部门。但题干说“不能含有humanresource部门”如果某个部门名是“xx human resource xx”这种不等于写法就排不掉。这种差异放到第5章再说。2.2 最高最低工资与CLERK过滤WHERE和GROUP BY的分工文档里emp表那一组题连续考了好几个变式列出各部门的部门号、最高工资、最低工资再进一步只统计job为CLERK的员工。先看最基础的一版-- emp表各部门最高最低工资 SELECT deptno, MAX(sal) AS max_sal, MIN(sal) AS min_sal FROM emp GROUP BY deptno;加上CLERK过滤后变成-- 仅统计CLERK岗位的部门最高最低工资 SELECT deptno, MAX(sal) AS max_sal, MIN(sal) AS min_sal FROM emp WHERE job CLERK GROUP BY deptno;两段代码的差别只有一行WHERE但语义完全不同。第一段统计的是部门里所有人的工资范围第二段先把行过滤到只剩CLERK再按部门分组。这个过滤发生在GROUP BY之前属于行级过滤所以用WHERE如果过滤条件针对的是分组后的聚合结果比如“只显示平均工资大于5000的部门”那就必须用HAVING。很多人在这个点上翻车把行级过滤写进HAVING或者反过来。文档里还有一道“每科大于90分的人数”的题走的是同样的逻辑。参考写法-- 每科大于90分的人数先按分数过滤再按课程分组 SELECT c.cname, COUNT(*) AS cnt FROM c JOIN sc ON c.cno sc.cno WHERE sc.grade 90 GROUP BY c.cname;这里JOIN条件写进ON成绩过滤条件写进WHERECOUNT统计的是过滤后每个课程分组里的行数。如果写成JOIN sc ON c.cno sc.cno AND sc.grade 90结果在绝大多数情况下一样但语义不清晰——ON里过滤会让人误以为连接条件本身包含成绩限制。我一般建议把行级过滤统一放WHEREON里只写表关联条件这样别人review代码时不用猜。2.3 题13的正确打开方式“人数多于1人”是一个HAVING文档里有一道题容易被忽略题干大致是对于emp表中工资高于本部门平均工资的员工列出部门号、人数要求人数多于1人按部门号排序。参考答案用了一长串嵌套子查询可读性很差。我建议用预聚合加HAVING来写-- 先算每个部门平均工资再统计高于平均工资的员工数 SELECT e.deptno, COUNT(*) AS emp_cnt FROM emp e JOIN ( SELECT deptno, AVG(sal) AS avg_sal FROM emp GROUP BY deptno ) d ON e.deptno d.deptno WHERE e.sal d.avg_sal GROUP BY e.deptno HAVING COUNT(*) 1 ORDER BY e.deptno;这段SQL的推演顺序是内层子查询先算出每个部门的平均工资外层员工表按deptno关联到对应部门的平均工资WHERE过滤掉工资不达标的员工GROUP BY按部门汇总人数HAVING再把人数不大于1的部门去掉。注意HAVING是在分组之后执行的所以能引用COUNT(*)这种聚合结果WHERE在这个阶段已经被执行完了想用WHERE COUNT(*) 1会直接报错。文档原答案用的是一条相关子查询思路没问题但子查询里还嵌套了一层聚合SQL Server执行时每行员工都要重新扫一遍同部门数据数据量小看不出差别数据量上去之后慢得能肉眼可见。我把这类问题放到第3章展开先记住一个结论能先用子查询把聚合结果算出来再关联就不要在WHERE里写复杂的相关子查询。3. 自连接与相关子查询把一张表当成两张表用工资对比类题目是这份文档的另一个重头戏比如“列出员工及其管理者姓名”“列出工资高于本部门平均水平的员工”“列出工资低于自己至少5人的员工”。这些题共同的特点是比较对象在同一个表里需要把一张表当成两张表来用。3.1 员工-管理者自连接MGR指向EMPNO文档里有一题要求对于emp中有管理者的员工列出员工姓名和管理者姓名。emp表里的mgr字段存的是管理者的empno所以答案是对emp表做自连接-- 自连接员工表与管理者表是同一张emp表 SELECT a.ename AS employee_name, b.ename AS manager_name FROM emp AS a JOIN emp AS b ON a.mgr b.empno WHERE a.mgr IS NOT NULL;这里必须给同一张表起两个别名否则SQL解析器分不清到底取哪个empno、哪个ename。a代表员工侧b代表管理者侧ON条件把a.mgr指向b.empno。WHERE a.mgr IS NOT NULL的作用是把没有管理者的员工排除掉比如董事长这一行的mgr通常是NULL。如果换一种需求“列出所有员工及其管理者没有管理者的也要显示”JOIN要改成LEFT JOIN并且去掉WHERE条件SELECT a.ename AS employee_name, b.ename AS manager_name FROM emp AS a LEFT JOIN emp AS b ON a.mgr b.empno;内连接和左外连接在这个场景下的差别很直观内连接只保留能匹配到管理者的行左外连接保留所有员工管理者列为NULL的依然输出。面试时如果只写了内连接版本可以主动补一句“如果要保留无管理者的员工改成LEFT JOIN”这比单纯写完答案更容易拿分。3.2 高于本部门平均工资相关子查询与预聚合的取舍文档里那道“列出工资高于本部门平均水平的员工按部门号排序”是相关子查询的经典题。直译写法是-- 相关子查询每个员工都要去查一次本部门平均工资 SELECT e.deptno, e.ename, e.sal FROM emp e WHERE e.sal ( SELECT AVG(sal) FROM emp b WHERE b.deptno e.deptno ) ORDER BY e.deptno;内层子查询引用外层e.deptno这就是“相关子查询”。执行时外层每处理一行员工内层就对同一个部门重新做一次AVG聚合。emp表只有十几行时无所谓如果是十万行员工、一万个部门最坏情况下内层要执行十万次聚合慢SQL优化里最忌讳的就是这种写法。更稳的写法是先把每个部门的平均工资算成一张小表再关联-- 预聚合先算部门平均工资再与员工表关联 SELECT e.deptno, e.ename, e.sal FROM emp e JOIN ( SELECT deptno, AVG(sal) AS avg_sal FROM emp GROUP BY deptno ) d ON e.deptno d.deptno WHERE e.sal d.avg_sal ORDER BY e.deptno;部门的数量通常远小于员工数量子查询d先分组聚合结果集很小外层JOIN只需要做一次哈希匹配整体成本低很多。两份文档里有一部分题目故意用相关子查询是为了考你懂不懂这个执行机制而不是鼓励你在生产环境里照抄。3.3 “低于自己工资至少5人”把问题翻译成计数子查询文档里有一道比较绕的题对于emp中低于自己工资至少5人的员工列出部门号、姓名、工资以及工资少于自己的人数。翻译成SQL就是统计比自己工资小的人数要求这个人数不少于5。-- 统计比自己工资低的员工人数要求至少5人 SELECT e.deptno, e.ename, e.sal, ( SELECT COUNT(*) FROM emp b WHERE b.sal e.sal ) AS lower_cnt FROM emp e WHERE ( SELECT COUNT(*) FROM emp b WHERE b.sal e.sal ) 5 ORDER BY e.sal;这道题有两个细节值得注意。第一条件写 5还是 5取决于“低于自己工资至少5人”是否包含自己。按字面意思“低于自己”不包括本人所以至少5人应该写成 5如果题目原意是“比自己工资少的人数为5个以上”就写 5。文档里参考答案写的是5我怀疑有偏差面试时最好跟面试官确认边界。第二这个查询会对每一行员工执行两次相同的内层子查询一次用于SELECT展示人数一次用于WHERE过滤。稍微优化一点的办法是用派生表把每个人的lower_cnt先算出来-- 用派生表消除重复子查询 SELECT deptno, ename, sal, lower_cnt FROM ( SELECT e.deptno, e.ename, e.sal, (SELECT COUNT(*) FROM emp b WHERE b.sal e.sal) AS lower_cnt FROM emp e ) t WHERE lower_cnt 5;这个版本的改写思路是内层派生表先计算出每个员工的lower_cnt外层过滤。逻辑上比写两遍子查询清晰也更好维护。生产环境如果数据量大更推荐用窗口函数比如ROW_NUMBER()按工资排序后做差值计算但那是另一个话题了。4. 同一道题不只一种写法TOP 1、JOIN与去重细节刷这份题集时你会发现很多题目给了不止一个参考答案比如不使用MIN取最小值、同一道汇总题用三种JOIN方式写。这些不同写法不是闲得没事而是对应不同的数据库方言和不同的数据场景。4.1 不用统计函数也要取最小值ORDER BY TOP的适用条件文档第29题很有意思给定Test(num INT)表用一条SQL返回num的最小值但不许使用MIN、MAX等统计功能。SQL Server下的标准答法是-- SQL Server升序取第一条 SELECT TOP 1 num FROM Test ORDER BY num ASC;逻辑是让ORDER BY完成数值排序然后取最上面一行。升序时第一条就是最小值降序时第一条就是最大值这就是TOP配合ORDER BY能干的事和MIN/MAX函数在语义上是等价的。如果换成MySQL或者PostgreSQL写法分别是LIMIT 1和FETCH FIRST 1 ROW ONLY-- MySQL / PostgreSQL对应LIMIT写法 SELECT num FROM Test ORDER BY num ASC LIMIT 1;这道题真正想考的不是你能不能写TOP而是你对“排序后取行”这种替代方案的理解。TOP 1在存在索引时可以只取一行成本很低但如果没有索引数据库需要把全表排完序再截取第一条数据量大时并不比MIN高效。另一个边界是如果Test表里num的最小值不止一行TOP 1只返回其中任意一行而SELECT MIN(num)聚合后只返回一个值两者在需要“最小值和对应的完整记录”时行为也不同。还有一个不使用统计函数的取法更贴近SQL理论num ALL (SELECT num FROM Test)。ALL子查询表示num小于或等于Test表中每一个num值这正好就是最小值的定义。笔试时写出这种写法面试官会知道你理解的是集合语义而不是背语法。4.2 “选出最高分的人”子查询与会漏掉并列的两个写法文档里有一道performance表题选出score最高的记录仅有一个。参考答案同时给了两种思路-- 写法一全表取最高分再用等值子查询匹配 SELECT name, score FROM performance WHERE score (SELECT MAX(score) FROM performance);-- 写法二直接按分数降序取第一条假设无并列 SELECT TOP 1 name, score FROM performance ORDER BY score DESC;写法和写法二在“仅有一个最高分”的前提下结果一致但适用场景不同。写法一在最高分有并列时返回所有并列者写法二只返回其中任意一条具体是哪一条取决于执行计划不具备确定性。如果题目改成“并列最高分也要全部列出”写法二直接失效写法一仍然正确。倒过来也值得注意如果题目要求“只返回一条记录哪怕有并列”写法一反而满足不了必须用写法二。面试时先问清楚“仅有一个”是不是确保数据就这么设计的再决定用哪种写法。文档里另一道题是“找出成绩最高的学生号”参考答案用的是WHERE grade (SELECT MAX(grade) FROM sc)和写法一是同一类处理并列没问题。4.3 Customer和Order的收入汇总三种JOIN方式语义不同文档第33题是customer表与order表要求算每个客户的Revenue总和。参考答案给了三种写法我先梳理一下。老式逗号连接-- 老式写法FROM后逗号WHERE写连接条件 SELECT customer.id, SUM([order].Revenue) AS total_revenue FROM customer, [order] WHERE [order].CustomerID customer.id GROUP BY customer.id;显式INNER JOIN-- 显式内连接 SELECT customer.id, SUM([order].Revenue) AS total_revenue FROM customer INNER JOIN [order] ON [order].CustomerID customer.id GROUP BY customer.id;FULL JOIN加NULL处理-- 全外连接保留没有订单的客户 SELECT customer.id, SUM(ISNULL([order].Revenue, 0)) AS total_revenue FROM customer FULL JOIN [order] ON [order].CustomerID customer.id GROUP BY customer.id;三种写法在“每个客户都有订单”的前提下结果一样但语义边界不同。前两种是内连接没有下过单的客户不会出现在结果里第三种FULL JOIN会保留所有客户没订单的客户Revenue方向上是NULL用ISNULL转成0才能正确求和。题目问的是“每个Customer的Revenue总和”没明确说没订单的客户是否要输出参考答案里三种都写了说明出题人也知道这里存在需求分歧。还有两个Syntax级别的坑。第一order是SQL关键字作为表名必须加方括号或者引号直接写FROM order, customer在任何主流数据库里都会报错。第二老式逗号连接里的WHERE customer.id customeridcustomerid这个列名在order表里是确定存在的但在customer表里不存在写全限定名[order].CustomerID更安全否则SQL Server会报列名歧义。文档原答案里甚至出现了order.revener这种拼写明显是把Revenue拼错了读到这种地方不要照抄改完再跑。在实际面试中还有一个隐含考点SUM(ISNULL([order].Revenue, 0))和SUM([order].Revenue)的差别只在FULL JOIN场景下体现内连接时没订单的行根本不会出现ISNULL可有可无。面试官追问“为什么用ISNULL”时如果回答从NULL与0求和结果差异切入比单纯背写法要加分。5. 避坑与常见问题五个让人在面试桌上翻车的细节这一节我挑了几个不是在讲SQL语义、而是依赖具体数据库和数据的坑。它们很少写进参考答案但只要碰到一次就够你难受半天的。5.1 human resource与humanresource看似相等实则不等现象用WHERE depart_name human resource过滤后human resource部门依然出现在结果里或者反过来明明存在这个部门却查不到任何数据。原因数据里存的可能是humanresource不带空格也可能是human resource两侧带了不可见空格或制表符。字符串比较是逐字符精确匹配空格差异直接导致条件失效。题干写的是一回事表里的数据可能是另一回事这在笔试题文档里最常见的坑就是字面量不匹配。解决先执行SELECT DISTINCT depart_name FROM employee;看清真实数据再写条件。如果数据带空格用TRIM处理字段或用LIKE模糊匹配。如果题意是“不能含有human resource”更严谨的写法是WHERE depart_name NOT LIKE %human resource%而不是不等于单个值。5.2 LEFT JOIN后用COUNT(*)还是COUNT(非空列)统计人数差出一倍现象customer表LEFT JOIN order表统计每个客户的订单数用COUNT(o.ID)和COUNT(*)得到的结果不一样没下过单的客户在两种写法下分别显示0和1。原因COUNT(*)统计的是结果集中的行数LEFT JOIN后这个客户也会保留一行所以是1COUNT(o.ID)只统计o.ID非NULL的行没订单的客户o.ID是NULL所以是0。两者的差异完全来自COUNT函数对NULL的处理策略不是数据错了。解决按业务语义决定。如果统计“订单行数”用COUNT(o.ID)如果统计“结果行数”用COUNT(*)。在文档第33题那种场景里SUM(ISNULL(Revenue, 0))也是同一类处理思路先把NULL转成0再求和避免最终结果显示空。写查询前想清楚NULL是算“没有”还是算“有”。5.3 旧版外连接写法在大版本升级后失效现象文档里有些老答案写成WHERE dept.deptno * emp.deptno拿到SQL Server 2005以上版本执行直接报语法错误。原因*和*是Sybase和早期SQL Server支持的外连接运算符ANSI SQL标准后来规定了LEFT/RIGHT OUTER JOIN的写法旧语法被弃用。这份题库里出现这种写法说明答案源自比较老的环境直接抄会翻车。解决改写为显式JOIN。比如文档里有一题“列出所有部门名、部门号以及各部门工作为CLERK的员工”需要保留没有CLERK员工的部门应该写SELECT d.dname, d.deptno, e.ename, e.job FROM dept d LEFT JOIN emp e ON e.deptno d.deptno AND e.job CLERK;注意e.job CLERK写在ON里而不是WHERE里。一旦写进WHERELEFT JOIN会被过滤成内连接没有任何CLERK员工的部门就从结果中消失了这正好违背“列出所有部门”的要求。5.4 GROUP BY缺列宽松模式掩盖的隐患现象SELECT depart_name, AVG(wage) FROM employee GROUP BY depart_id在MySQL默认配置下能跑通但换成SQL Server直接报错或者MySQL开了only_full_group_by之后也报错报错信息指出depart_name不在GROUP BY中。原因MySQL默认关闭了only_full_group_bySELECT里可以出现没有参与分组的非聚合列数据库会从分组中随机取一个值返回结果不确定。文档里的参考答案大多是完整写法但如果你自己改写时漏了列很容易在宽松模式下漏掉这个错。解决把非聚合列写全要么加进GROUP BY要么用聚合函数包住。上面这段代码应该写成GROUP BY depart_id, depart_name或者GROUP BY depart_id后SELECT里只保留depart_id。写查询时养成习惯SELECT里有几个非聚合列GROUP BY里就放几个。5.5 中文列名与排序规则ORDER BY结果随环境漂移现象相同一条ORDER BY depart_name在本地SQL Server里按拼音排序在线上MySQL里按UTF-8编码排序两边结果顺序不同面试时被追问“按什么规则排”答不上来。原因字符排序依赖数据库的Collation/排序规则。SQL Server简体中文环境默认按拼音权重排序MySQL utf8mb4_general_ci按Unicode编码顺序排序英文环境又是一种顺序。字符串排序不像数字排序那么唯一环境一变结果就变。解决面试时说清楚题意是“字典序”还是“数据库当前排序规则”如果要求固定顺序在ORDER BY里显式指定COLLATE。生产环境不要依赖默认排序规则前端分页和数据导出都要在SQL层面确定排列依据否则换个实例结果对不上这是典型的SLOW SQL和线上事故隐患。6. 建库实测代替背答案三步验证和变体自测刷这份题最忌讳的方式是看一遍答案觉得“会了”合上文档就忘。第5章那些坑全是真实建库跑一遍才能暴露出来的东西。我现在刷任何SQL题目都强迫自己走一套固定流程建表、造数、跑每条SQL再故意改条件做变体验证。第一步把题库里的核心表建到本地。推荐先建最常用的emp和dept两张表-- 建表部门表与员工表 CREATE TABLE dept ( deptno INT PRIMARY KEY, dname VARCHAR(50), loc VARCHAR(50) ); CREATE TABLE emp ( empno INT PRIMARY KEY, ename VARCHAR(50), job VARCHAR(50), mgr INT, sal DECIMAL(10,2), deptno INT ); -- 三行代表性数据 INSERT INTO dept VALUES (10, ACCOUNTING, NEW YORK); INSERT INTO dept VALUES (20, RESEARCH, DALLAS); INSERT INTO dept VALUES (30, SALES, CHICAGO); INSERT INTO emp VALUES (7369, SMITH, CLERK, 7902, 800, 20), (7499, ALLEN, SALESMAN, 7698, 1600, 30), (7788, SCOTT, ANALYST, 7566, 3000, 20);这段脚本在SQL Server和MySQL下几乎通用唯一要注意的是VARCHAR长度和DECIMAL精度按需调整。数据不要贪多每个部门两三行足够验证分组逻辑。第二步跑完答案后用EXPLAIN看执行计划。比如第3章的相关子查询版本与预聚合JOIN版本在emp表里看不出差别但用EXPLAIN SELECT ...一看相关子查询的select_type是DEPENDENT SUBQUERY意味着每行要重复执行子查询预聚合JOIN版本是DERIVED加普通JOIN。数据量放大之后这两个版本的耗时差距就出来了。看执行计划是判断题目答案能否用于生产的最快方式。第三步出变体题自测。我常用的做法是改三个条件把“排除human resource部门”改成“排除部门名中包含human resource的所有部门”把换成NOT LIKE把“选出最高分员工”改成“选出第二高分的员工”用WHERE score (SELECT MAX(score)...)倒推把“每科大于90分的人数”改成“每科平均分大于90的课程”过滤条件从WHERE挪到HAVING。每改一个条件都追问自己一句SQL里的哪段逻辑要跟着变哪个关键字要换位置。我前年面一个岗位时吃过亏背熟了文档里“低于自己工资至少5人”的原版答案结果面试官把条件改成“不少于5人”我当场卡住因为没想清楚边界条件是要写还是。从那以后我每次刷题库都会强制自己走一遍建库实测加三步验证把每题都改成至少两个变体跑通。这份文档的价值不在于让你背下几十条答案而在于它给了你足够多可以二次加工的题目素材。希望帮到你。本文还有配套的精品资源点击获取