简介本资源是一份面向高校数据库课程初学者的嵌套查询专项实验报告聚焦SQL高级查询能力训练适用于数据库原理、数据库系统实验等课程的课后巩固与考前复习。文档完整覆盖统计查询、聚合函数SUM/COUNT/MAX/MIN、多表连接INNER/LEFT/RIGHT JOIN及核心嵌套查询技术子查询、相关子查询、派生表包含14道典型实操题及其完整SQL语句与执行逻辑说明如上海客户订单筛选、同城市客户关联查询、高价产品比对等真实业务场景。资源为单文件Word文档.doc大小642KB结构清晰、注释详尽便于直接运行验证与笔记批注。目前已有931人学习下载是掌握SELECT进阶语法、理解WHERE/HAVING/GROUP BY嵌套关系及提升复杂查询建模能力的实用教学材料。1. 这不是“写SQL题”而是让你第一次真正看懂数据库在「替你思考」你有没有过这种感觉打开一个表格软件想查“上海的客户买了多少东西”结果要手动筛选城市、再复制粘贴数量、再加总——手忙脚乱还容易漏其实数据库早就在干这件事它不存死数据而像一个会算账、能记事、还带记忆的智能小助手。你只要说清楚“我要什么”它就自动翻表、比对、汇总、过滤最后把答案干干净净交给你。这份《数据库实验5嵌套查询》就是带你亲手调教它的第一课——不是背命令而是学会用“人话”指挥数据库干活。里面所有例子都来自真实业务场景查哪些客户最活跃、哪些产品卖得最猛、谁和谁在同一个城市、哪个产品还没被买过……它不教你“数据库是什么”它直接让你看到原来一行SELECT就能代替我手动翻十页Excel原来一个括号里的子查询就是在让数据库先去查一遍“美美公司在哪”再按这个结果去找其他公司。适合谁零基础但敢点开SQL编辑器的新手刚学完建表、插数据却卡在“怎么把数据用起来”的同学或者被老板临时问“上个月上海客户下单超200的有哪些”当场愣住的职场新人。别怕报错这门课的全部意义就是让你从“不敢敲”变成“敲完就知道错在哪、为什么错、怎么改”。2. 先搞懂一个概念嵌套查询不是“套娃”而是“分步提问”很多人一看到SELECT ... WHERE ... (SELECT ...)就头皮发紧觉得是“SQL套娃”越套越晕。其实完全不是。嵌套查询的本质是把一个复杂问题拆成两步或三步清晰的提问。就像你问助理“帮我找找和‘美美公司’同城的客户”助理不会凭空猜而是先做第一步查出“美美公司”在哪儿再做第二步拿着这个地址去客户表里挨个比对。数据库也是这么工作的——外层查询负责“要什么结果”内层查询也就是括号里的那个只干一件事先算出一个确定的答案交给外层用。2.1 嵌套查询的三种典型长相你一眼就能认出来我们不用术语轰炸直接看实验里最常出现的三种样子每种都配一句大白话翻译WHERE 后面跟括号最常见SELECT CNAME, TELE FROM CUSTOMER WHERE SITE (SELECT SITE FROM CUSTOMER WHERE CNAME 美美);大白话“先去客户表里找‘美美公司’的地址SITE找到后再把所有地址和这个结果一样的客户名字和电话给我。”✅ 关键特征、!、IN这些比较符后面直接跟(SELECT ...)内层必须返回单个值比如一个城市名否则会报错。FROM 后面跟括号叫“派生表”SELECT CNO, SUM(OQUANTITY) AS TOTAL_QTY FROM (SELECT CNO, OQUANTITY FROM SALE WHERE OQUANTITY 100) AS BIG_ORDERS GROUP BY CNO;大白话“先从订单表里筛出所有大于100的单子把这张临时小表起名叫 BIG_ORDERS再对这张小表按客户编号汇总数量。”✅ 关键特征(SELECT ...)出现在FROM后面后面必须跟AS 别名内层可以返回多行多列它就是一张“临时表”。SELECT 列表里直接写子查询叫“标量子查询”SELECT PCODE, PNAME, (SELECT COUNT(*) FROM SALE WHERE SALE.PCODE PRODUCT.PCODE) AS ORDER_TIMES FROM PRODUCT;大白话“查每个产品编号和名称同时对每个产品单独去订单表里数一数它被订了多少次把这个数字作为一列显示出来。”✅ 关键特征(SELECT ...)出现在SELECT后面和字段并列内层必须返回单个值一行一列而且通常要和外层表有连接条件比如这里的SALE.PCODE PRODUCT.PCODE不然会算错。记住所有嵌套核心就一条——内层先跑完得出一个明确结果外层再拿这个结果去干活。它不是魔法只是把“先查A再用A的结果查B”这两步压缩成了一条语句。2.2 为什么非得用嵌套三个你马上会遇到的真实理由新手常问“我用两个独立查询不行吗干嘛非得套在一起”——当然可以但你会立刻掉进效率、准确性和可维护性的坑里。来看实验里这几个例子怎么暴露问题理由1避免重复劳动防止数据不一致实验第12题查和“美美公司”同城的客户。如果分两步第一步查出“美美”在“上海”第二步再查WHERE SITE上海——看起来没问题。但如果“美美公司”地址改了你得手动改两次而嵌套查询里地址只在一个地方内层定义改一次全链路自动更新。理由2解决“动态参照”问题这是普通连接做不到的实验第13题查单价比“A01”高的产品。A01的单价是多少你根本不知道它可能今天是15明天调成18。普通JOIN要求两张表有固定关联字段但这里没有“产品A01的单价”这张现成的表。嵌套查询直接让它现场查“A01多少钱→ 得到15 → 再去找所有价格15的产品”。这是动态的、基于值的参照不是基于字段的关联。理由3实现“存在性判断”这是统计函数无法替代的实验第14题查“没被订购过”的产品。你不能用COUNT()算因为COUNT()只能告诉你“被订了多少次”但0次和NULL在聚合里处理很麻烦。嵌套用NOT IN或NOT EXISTS就非常直白“找出那些产品编号不在订单表的PCODE列表里”。这是一种逻辑判断不是数值计算。所以嵌套不是炫技它是数据库给你的一把“瑞士军刀”当问题需要“先知道一个值再用它筛选”“需要动态参照”“需要判断存在与否”时它就是最自然、最可靠的解法。2.3 常见问题新手写嵌套查询最容易踩的5个坑提示这些坑我第一次写嵌套时全踩过重装三次数据库才搞明白。现在列出来帮你省下三天调试时间。现象运行SELECT ... WHERE SITE (SELECT SITE FROM CUSTOMER WHERE CNAME美美)报错 “Subquery returns more than 1 row”子查询返回多于1行原因内层查询SELECT SITE FROM CUSTOMER WHERE CNAME美美找到了两条记录比如有两个“美美公司”。要求右边只能是一个值但你给了它两个。解决加LIMIT 1强制取第一个或用IN替代WHERE SITE IN (...)但更治本的是检查数据——为什么会有重名是否该用唯一编号如CNO而非名称做查找现象SELECT ... FROM (SELECT ... ) AS T报错 “Every derived table must have its own alias”每个派生表必须有自己的别名原因MySQL强制要求FROM后面的子查询必须用AS 别名命名哪怕你只是临时用一下。漏写AS T就会报这个错。解决死记硬背凡是在FROM后面出现的(...)后面必跟AS XXX。别名可以是任意合法名字比如AS TEMP、AS FILTERED_SALES。现象SELECT PCODE, (SELECT COUNT(*) FROM SALE WHERE SALE.PCODEPRODUCT.PCODE) ... FROM PRODUCT返回全是0或NULL原因外层PRODUCT表和内层SALE表的连接条件写错了。常见错误是写成SALE.PCODEPCODE没指定表名数据库不知道PCODE是指哪个表的可能默认为内层表导致条件失效。解决永远给字段加上表名前缀写成SALE.PCODE PRODUCT.PCODE。这是血泪经验——不加前缀90%的标量子查询都会逻辑错误。现象SELECT ... WHERE PCODE ! (SELECT PCODE FROM SALE)查不到任何“没被订购的产品”原因!和NULL在SQL里是“失联”关系。如果子查询返回NULL比如SALE表为空PCODE ! NULL的结果永远是UNKNOWN不是TRUE所以整行被过滤掉。正确做法是用NOT IN或NOT EXISTS。解决查“不存在”的场景无条件用NOT IN或NOT EXISTS。例如WHERE PCODE NOT IN (SELECT PCODE FROM SALE)。注意NOT IN如果子查询含NULL结果也会全空此时改用NOT EXISTS更安全实验第14题原写法!就是典型错误应改为NOT IN。现象嵌套查询执行极慢几秒没反应甚至卡死原因内层查询没有索引且在外层循环中被反复执行。比如标量子查询SELECT ..., (SELECT ...) FROM PRODUCT如果PRODUCT有1万行内层SELECT COUNT(*) FROM SALE...就会被执行1万次解决优先用JOIN代替标量子查询如用LEFT JOIN SALE ON ... GROUP BY替代SELECT (SELECT ...)如果必须用子查询确保内层WHERE条件字段如SALE.PCODE已建索引。这是性能玄学但新手起步就该建立意识。3. 先跑通第一个嵌套从“查同城客户”开始手把手敲出第一行有效SQL别急着背所有语法我们只聚焦实验第12题——它最简单、最直观且100%能跑通。跟着下面步骤你将亲手打出人生第一个真正有用的嵌套查询并理解每一部分在干什么。假设你已经安装好MySQL或类似数据库并成功导入了CPXS数据库含CUSTOMER、SALE、PRODUCT三张表。3.1 第一步确认数据先看看“美美公司”到底在哪儿在你的数据库客户端如MySQL Workbench、DBeaver或命令行里先执行这一句SELECT CNO, CNAME, SITE FROM CUSTOMER WHERE CNAME 美美;✅ 这不是嵌套是“探路”。目的是确认表里真有叫“美美”的客户避免拼写错误比如写成“美美公司”或“美美有限公司”它的SITE字段值是什么比如是“上海”还是“上海市”空格、标点都要一致它的CNO是多少后续可能用到。如果这句返回空说明数据里没有“美美”你需要换成实验里存在的客户名比如“华美”或“宏达”看CUSTOMER表实际数据。3.2 第二步写出内层查询单独验证它是否返回单个值把上一步查到的SITE值假设是“上海”填进去执行SELECT SITE FROM CUSTOMER WHERE CNAME 美美;✅ 这句必须只返回一行一列比如就一个“上海”。如果返回多行说明有重名按2.3节第一个坑处理如果返回空说明名字不对。只有这句稳了才能进下一步。3.3 第三步组装外层查询用内层结果做筛选条件现在把第二步的结果当作一个“已知答案”放进外层查询的WHERE条件里SELECT CNAME, TELE FROM CUSTOMER WHERE SITE 上海;✅ 这句是“模拟版”先手动把‘上海’写死确认逻辑对不对它应该列出所有地址是上海的客户名和电话。如果这句能跑说明外层结构没问题。3.4 第四步正式嵌套——把“上海”替换成子查询把第三步里的上海替换成第二步的整个查询记得加括号SELECT CNAME, TELE FROM CUSTOMER WHERE SITE (SELECT SITE FROM CUSTOMER WHERE CNAME 美美);✅ 这就是最终的嵌套查询执行它。你应该看到和第三步相同的结果所有上海客户但这次数据库是自己查出来的“上海”而不是你手动写的。 关键参数说明SELECT SITE FROM CUSTOMER WHERE CNAME 美美内层负责“找答案”必须返回单值WHERE SITE (...)外层负责“用答案”表示严格匹配单个值整个语句的逻辑链条先查美美在哪 → 得到“上海” → 再查所有地址是“上海”的客户。3.5 第五步举一反三改一个参数立刻得到新结果现在把美美换成另一个客户名比如宏达SELECT CNAME, TELE FROM CUSTOMER WHERE SITE (SELECT SITE FROM CUSTOMER WHERE CNAME 宏达);✅ 不用改任何其他地方只换名字就能立刻查出和“宏达”同城的所有客户。这就是嵌套查询的威力——参数化。你封装了一个逻辑“查同城客户”只需要改一个输入客户名就能复用无数次。以后写报表、做后台接口全靠这种思路。提示如果执行报错请立刻回到2.3节对照那5个坑逐一排查。90%的问题都出在内层返回多行、没加表名前缀、或用了!而不是NOT IN上。4. 统计函数和分组查询嵌套的“搭档”不是对手很多新手以为嵌套查询是“高阶技巧”得等学完所有基础才能碰。其实恰恰相反——它和COUNT、SUM、GROUP BY这些基础操作是天然搭档经常一起出场。实验里大量题目如第2、3、5题表面看是分组统计但它们正是嵌套查询的“前置训练”和“最佳拍档”。我们不把它当独立章节学而是直接看它怎么和嵌套配合发力。4.1 分组统计GROUP BY是“分堆”嵌套是“挑堆”先看实验第2题SELECT CNO, COUNT(PCODE) FROM SALE GROUP BY CNO HAVING COUNT(PCODE) 2;这句在做什么它先把订单表SALE按客户编号CNO“分堆”每堆是一个客户的所有订单然后对每堆数一数有多少个产品COUNT(PCODE)最后用HAVING把“堆里产品数2”的那些客户挑出来。✅GROUP BY解决的是“按什么维度分组”HAVING是对分组后的结果做筛选注意不是WHEREWHERE是分组前筛HAVING是分组后筛。现在如果需求升级“查出这些‘至少订了2种产品’的客户中谁的总订购量最大”这就需要嵌套了——外层要排序取最大内层先算出每个客户的总订购量SELECT CNO, TOTAL_QTY FROM ( SELECT CNO, SUM(OQUANTITY) AS TOTAL_QTY FROM SALE GROUP BY CNO HAVING COUNT(PCODE) 2 ) AS ACTIVE_CUSTOMERS ORDER BY TOTAL_QTY DESC LIMIT 1;✅ 解析内层括号里就是第2题的逻辑但加了SUM(OQUANTITY)计算总数量并起别名TOTAL_QTY外层把内层结果当一张新表ACTIVE_CUSTOMERS再对TOTAL_QTY降序排列取第一行。这就是典型的“分组嵌套”GROUP BY负责精细切分和聚合嵌套负责把聚合结果当数据再加工。4.2 统计函数COUNT/SUM/MAX/MIN是“计算器”嵌套是“调度员”实验第5题SELECT MAX(PRICE) FROM PRODUCT很简单就是查最高价。但如果你要“查出最高价对应的产品名称和编号”就不能只用MAX()了因为MAX()只返回值不返回整行。这时嵌套就来调度SELECT PCODE, PNAME, PRICE FROM PRODUCT WHERE PRICE (SELECT MAX(PRICE) FROM PRODUCT);✅ 这里MAX(PRICE)是内层的“计算器”它算出一个数字比如99.9外层的WHERE PRICE ...是“调度员”拿着这个数字去主表里找到所有价格等于它的产品注意可能有多个同价产品所以用而不是LIMIT 1。对比如果用ORDER BY PRICE DESC LIMIT 1只能取一个且无法保证是“所有最高价产品”。4.3 避坑HAVING 和 WHERE 的混淆是新手分组查询最大雷区提示这个坑几乎每个初学者都踩过而且很难自己发现。错误写法实验第4题原题SELECT SITE, COUNT(CNO) FROM CUSTOMER GROUP BY SITE HAVING SITE 上海; -- ❌ 错现象可能返回空或报错。原因HAVING是对分组后的结果即每个SITE对应的COUNT(CNO)做筛选但它不能用来筛选分组依据字段本身。SITE 上海应该在分组前就确定范围属于WHERE的职责。正确写法SELECT SITE, COUNT(CNO) FROM CUSTOMER WHERE SITE 上海 -- ✅ 放这里先筛出上海客户 GROUP BY SITE; -- 再按SITE分组此时SITE只有上海一个值✅ 记住口诀“WHERE 筛行GROUP BY 分堆HAVING 筛堆”。你想筛的是原始数据行如“只要上海的客户”用WHERE你想筛的是分组后的聚合结果如“只要客户数超过10的城市”用HAVING。另一个经典错误实验第6题原题SELECT COUNT(PCODE) FROM PRODUCT GROUP BY STOCKS HAVING STOCKS 500; -- ❌ 错现象返回多行每行一个COUNT(PCODE)但你要的是“库存500的产品总数”。原因GROUP BY STOCKS把产品按库存量分成了无数堆比如库存100一堆、200一堆…HAVING STOCKS500是在筛“库存量字段值500”的那些堆但每堆里COUNT(PCODE)是1因为每堆只有一种库存值结果就是一堆1。正确写法不需要分组SELECT COUNT(PCODE) FROM PRODUCT WHERE STOCKS 500; -- ✅ 直接筛行再统计总数✅ 总结当你要的是“满足某条件的记录总数”用WHERE COUNT当你要的是“按某字段分组后每组的统计值”才用GROUP BY COUNT。5. 连接查询JOIN和嵌套查询不是二选一而是“何时用哪个”的决策树新手常陷入一个误区学了JOIN就觉得嵌套是“过时写法”学了嵌套又觉得JOIN是“绕远路”。其实它们是数据库的左右手各有不可替代的场景。实验里第11、13题明显是JOIN第12、14题明显是嵌套但第13题如果写成嵌套也完全可行。关键不是哪个高级而是哪个更清晰、更安全、更易维护。5.1 一张表 vs 多张表先看数据在不在一张表里这是最根本的判断起点。数据在同一张表→ 优先考虑嵌套查询实验第12题查和“美美公司”同城的客户。所有信息客户名、地址都在CUSTOMER表里。你不需要拉其他表只需要“在本表里先查A再用A查B”。嵌套最直接。数据在不同张表→ 优先考虑JOIN实验第11题查由上海客户订购的订单要客户名、产品号、数量。客户信息在CUSTOMER表订单信息在SALE表。必须把两张表连起来JOIN是天选之子SELECT SALE.CNO, SALE.PCODE, CUSTOMER.CNAME, SALE.OQUANTITY FROM SALE INNER JOIN CUSTOMER ON SALE.CNO CUSTOMER.CNO WHERE CUSTOMER.SITE 上海 AND SALE.OQUANTITY 200;✅JOIN清晰表达了“关联关系”CNO是连接键且性能通常优于等价的嵌套因为数据库优化器对JOIN更友好。5.2 逻辑是“关联”还是“存在性判断”决定用 JOIN 还是 NOT IN/EXISTS这是第二个关键决策点。需要“关联出详细信息”如客户名、产品名、联系电话→ 用JOIN实验第13题查单价比A01高的产品还要显示产品编号、客户编号、数量。这些字段分散在PRODUCT和SALE表JOIN可以一次性拉出所有需要的列。只需要“判断是否存在”如“这个产品有没有被订过”“这个客户有没有下过单”→ 用NOT IN或NOT EXISTS实验第14题查“没被订购的产品”。你只关心“PCODE 是否在 SALE 表里出现过”不关心订单详情。用NOT IN最简洁SELECT PCODE, PNAME FROM PRODUCT WHERE PCODE NOT IN (SELECT PCODE FROM SALE);✅ 比LEFT JOIN ... WHERE SALE.PCODE IS NULL更易读且在某些情况下性能更好尤其当SALE表很大时NOT IN可能提前终止。5.3 性能与可读性权衡JOIN 更快嵌套更“自解释”性能角度现代数据库MySQL 8.0, PostgreSQL对JOIN的优化极其成熟同等逻辑下JOIN通常比等价嵌套快10%-50%。因为优化器能更好地估算数据分布、选择连接算法Hash Join, Merge Join。可读性角度嵌套查询像一篇短文逻辑是线性的“先做A再用A做B”。JOIN像一张关系图需要你脑补连接路径。对于复杂多表关联嵌套反而更清晰。例如查“订购了上海客户所购产品的其他客户”用嵌套可以分三步写-- 步骤1上海客户买了哪些产品 -- 步骤2哪些客户买了这些产品排除上海客户 -- 步骤3查这些客户的详细信息而JOIN版本可能需要三层JOIN加复杂ON条件一眼看不出主干。所以我的建议血泪经验新手起步优先用嵌套它逻辑直、报错明、调试易能让你100%理解自己在干什么项目上线逐步替换为JOIN当逻辑稳定、数据量上来后用EXPLAIN分析执行计划把高频查询换成JOIN永远把可读性放第一位如果一个嵌套查询你能在3秒内读懂它在做什么那就别为了“显得高级”硬改成JOIN。代码是写给人看的顺便让机器执行。6. 下一步学什么从“会写”到“写得好”的三步进阶路径你现在能跑通第一个嵌套查询能区分WHERE和HAVING能判断什么时候该用JOIN、什么时候该用NOT IN——这已经超过了80%刚入门的同学。但真正的数据库能力不在于会写多少种语法而在于面对一个新需求时能快速拆解、精准选型、写出健壮可维护的SQL。接下来我建议你按这个顺序花一周时间每天专注一个方向把基础打牢。6.1 第一步用好“执行计划”告别盲写1天别再靠猜和试错。所有主流数据库都提供EXPLAIN命令它能告诉你数据库打算怎么执行你的SQL。这是你和数据库对话的“翻译器”。怎么做在你写好的任何查询前加上EXPLAIN比如EXPLAIN SELECT CNAME, TELE FROM CUSTOMER WHERE SITE (SELECT SITE FROM CUSTOMER WHERE CNAME 美美);怎么看关键信息以MySQL为例type列ALL表示全表扫描慢ref或eq_ref表示走了索引好rows列预估扫描行数越小越好Extra列出现Using filesort或Using temporary是性能红灯。行动清单① 对实验里所有查询逐个加EXPLAIN记录type和rows② 给CUSTOMER.SITE和CUSTOMER.CNAME字段创建索引CREATE INDEX idx_site ON CUSTOMER(SITE); CREATE INDEX idx_cname ON CUSTOMER(CNAME);③ 再EXPLAIN对比rows是否大幅下降。你会发现加索引后原本扫1000行的查询可能只扫5行。这就是“让数据库飞起来”的第一步。6.2 第二步掌握窗口函数解锁“动态排名”“移动平均”2天COUNT、SUM是静态聚合只能给你一个总数。但业务中更多是“每个客户自己的销售额排名”“最近3个月的平均销量”。这就是窗口函数Window Function的领域它是SQL 2003标准MySQL 8.0、PostgreSQL、SQL Server 全支持。一个救命例子实验第3题是“每个客户订购数量总数”但如果要“每个客户订购数量总数并按金额从高到低排名”用传统GROUP BY 子查询会非常绕。用窗口函数一行搞定SELECT CNO, SUM(OQUANTITY) AS TOTAL_QTY, RANK() OVER (ORDER BY SUM(OQUANTITY) DESC) AS RANKING FROM SALE GROUP BY CNO;学习路径① 先掌握ROW_NUMBER(),RANK(),DENSE_RANK()三兄弟的区别重点看并列时的编号逻辑② 再学SUM() OVER (PARTITION BY ... ORDER BY ...)做分组内累计求和③ 最后练AVG() OVER (ORDER BY ... ROWS BETWEEN 2 PRECEDING AND CURRENT ROW)做移动平均。为什么推荐因为窗口函数是“嵌套查询的进化版”——它把“先分组再对每组排序/累计”的逻辑压缩进一个函数里代码更短性能更好且天然支持ORDER BY这是老式嵌套做不到的。6.3 第三步动手写一个“可复用的查询模板”固化你的方法论2天不要停留在“做题”。把你学到的模式封装成一个随时能抄的模板。我当年做的第一个模板就是“查同城客户”的增强版-- 【模板】查与指定客户同城的所有客户含防错、注释、可配置 SELECT c1.CNO AS TARGET_CNO, -- 目标客户编号 c1.CNAME AS TARGET_NAME, -- 目标客户名称 c2.CNO AS SAME_CITY_CNO, -- 同城客户编号 c2.CNAME AS SAME_CITY_NAME, -- 同城客户名称 c2.TELE AS SAME_CITY_TELE -- 同城客户电话 FROM CUSTOMER c1 INNER JOIN CUSTOMER c2 ON c1.SITE c2.SITE -- 核心同城即SITE相等 WHERE c1.CNAME 美美 -- ← 这里改成你要查的客户名 AND c2.CNAME ! 美美 -- 排除自己 AND c1.SITE IS NOT NULL -- 防NULL导致结果异常 AND c2.SITE IS NOT NULL;这个模板的价值有表别名c1,c2避免字段歧义有完整注释说明每行作用有防错逻辑IS NOT NULL有明确的修改提示← 这里改成...用JOIN实现比嵌套更高效且能同时拿到目标客户和同城客户的所有字段。你的任务① 把实验第13题查高价产品也写成一个带注释、可配置的模板把A01设为变量② 把第14题查未订购产品用NOT EXISTS重写并加入COALESCE处理可能的NULL③ 把这三个模板存成.sql文件命名为template_same_city.sql、template_high_price.sql、template_unordered.sql。从那以后我每次接到新需求第一反应不是打开编辑器狂敲而是翻出这几个模板复制、粘贴、改参数、加字段。真正的效率不是写得快而是不重复造轮子把80%的通用逻辑固化成肌肉记忆。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/27 11:58:21 · 阅读 1.2k SQL嵌套查询入门：用分步提问思维看懂数据库如何替你思考
简介本资源是一份面向高校数据库课程初学者的嵌套查询专项实验报告聚焦SQL高级查询能力训练适用于数据库原理、数据库系统实验等课程的课后巩固与考前复习。文档完整覆盖统计查询、聚合函数SUM/COUNT/MAX/MIN、多表连接INNER/LEFT/RIGHT JOIN及核心嵌套查询技术子查询、相关子查询、派生表包含14道典型实操题及其完整SQL语句与执行逻辑说明如上海客户订单筛选、同城市客户关联查询、高价产品比对等真实业务场景。资源为单文件Word文档.doc大小642KB结构清晰、注释详尽便于直接运行验证与笔记批注。目前已有931人学习下载是掌握SELECT进阶语法、理解WHERE/HAVING/GROUP BY嵌套关系及提升复杂查询建模能力的实用教学材料。1. 这不是“写SQL题”而是让你第一次真正看懂数据库在「替你思考」你有没有过这种感觉打开一个表格软件想查“上海的客户买了多少东西”结果要手动筛选城市、再复制粘贴数量、再加总——手忙脚乱还容易漏其实数据库早就在干这件事它不存死数据而像一个会算账、能记事、还带记忆的智能小助手。你只要说清楚“我要什么”它就自动翻表、比对、汇总、过滤最后把答案干干净净交给你。这份《数据库实验5嵌套查询》就是带你亲手调教它的第一课——不是背命令而是学会用“人话”指挥数据库干活。里面所有例子都来自真实业务场景查哪些客户最活跃、哪些产品卖得最猛、谁和谁在同一个城市、哪个产品还没被买过……它不教你“数据库是什么”它直接让你看到原来一行SELECT就能代替我手动翻十页Excel原来一个括号里的子查询就是在让数据库先去查一遍“美美公司在哪”再按这个结果去找其他公司。适合谁零基础但敢点开SQL编辑器的新手刚学完建表、插数据却卡在“怎么把数据用起来”的同学或者被老板临时问“上个月上海客户下单超200的有哪些”当场愣住的职场新人。别怕报错这门课的全部意义就是让你从“不敢敲”变成“敲完就知道错在哪、为什么错、怎么改”。2. 先搞懂一个概念嵌套查询不是“套娃”而是“分步提问”很多人一看到SELECT ... WHERE ... (SELECT ...)就头皮发紧觉得是“SQL套娃”越套越晕。其实完全不是。嵌套查询的本质是把一个复杂问题拆成两步或三步清晰的提问。就像你问助理“帮我找找和‘美美公司’同城的客户”助理不会凭空猜而是先做第一步查出“美美公司”在哪儿再做第二步拿着这个地址去客户表里挨个比对。数据库也是这么工作的——外层查询负责“要什么结果”内层查询也就是括号里的那个只干一件事先算出一个确定的答案交给外层用。2.1 嵌套查询的三种典型长相你一眼就能认出来我们不用术语轰炸直接看实验里最常出现的三种样子每种都配一句大白话翻译WHERE 后面跟括号最常见SELECT CNAME, TELE FROM CUSTOMER WHERE SITE (SELECT SITE FROM CUSTOMER WHERE CNAME 美美);大白话“先去客户表里找‘美美公司’的地址SITE找到后再把所有地址和这个结果一样的客户名字和电话给我。”✅ 关键特征、!、IN这些比较符后面直接跟(SELECT ...)内层必须返回单个值比如一个城市名否则会报错。FROM 后面跟括号叫“派生表”SELECT CNO, SUM(OQUANTITY) AS TOTAL_QTY FROM (SELECT CNO, OQUANTITY FROM SALE WHERE OQUANTITY 100) AS BIG_ORDERS GROUP BY CNO;大白话“先从订单表里筛出所有大于100的单子把这张临时小表起名叫 BIG_ORDERS再对这张小表按客户编号汇总数量。”✅ 关键特征(SELECT ...)出现在FROM后面后面必须跟AS 别名内层可以返回多行多列它就是一张“临时表”。SELECT 列表里直接写子查询叫“标量子查询”SELECT PCODE, PNAME, (SELECT COUNT(*) FROM SALE WHERE SALE.PCODE PRODUCT.PCODE) AS ORDER_TIMES FROM PRODUCT;大白话“查每个产品编号和名称同时对每个产品单独去订单表里数一数它被订了多少次把这个数字作为一列显示出来。”✅ 关键特征(SELECT ...)出现在SELECT后面和字段并列内层必须返回单个值一行一列而且通常要和外层表有连接条件比如这里的SALE.PCODE PRODUCT.PCODE不然会算错。记住所有嵌套核心就一条——内层先跑完得出一个明确结果外层再拿这个结果去干活。它不是魔法只是把“先查A再用A的结果查B”这两步压缩成了一条语句。2.2 为什么非得用嵌套三个你马上会遇到的真实理由新手常问“我用两个独立查询不行吗干嘛非得套在一起”——当然可以但你会立刻掉进效率、准确性和可维护性的坑里。来看实验里这几个例子怎么暴露问题理由1避免重复劳动防止数据不一致实验第12题查和“美美公司”同城的客户。如果分两步第一步查出“美美”在“上海”第二步再查WHERE SITE上海——看起来没问题。但如果“美美公司”地址改了你得手动改两次而嵌套查询里地址只在一个地方内层定义改一次全链路自动更新。理由2解决“动态参照”问题这是普通连接做不到的实验第13题查单价比“A01”高的产品。A01的单价是多少你根本不知道它可能今天是15明天调成18。普通JOIN要求两张表有固定关联字段但这里没有“产品A01的单价”这张现成的表。嵌套查询直接让它现场查“A01多少钱→ 得到15 → 再去找所有价格15的产品”。这是动态的、基于值的参照不是基于字段的关联。理由3实现“存在性判断”这是统计函数无法替代的实验第14题查“没被订购过”的产品。你不能用COUNT()算因为COUNT()只能告诉你“被订了多少次”但0次和NULL在聚合里处理很麻烦。嵌套用NOT IN或NOT EXISTS就非常直白“找出那些产品编号不在订单表的PCODE列表里”。这是一种逻辑判断不是数值计算。所以嵌套不是炫技它是数据库给你的一把“瑞士军刀”当问题需要“先知道一个值再用它筛选”“需要动态参照”“需要判断存在与否”时它就是最自然、最可靠的解法。2.3 常见问题新手写嵌套查询最容易踩的5个坑提示这些坑我第一次写嵌套时全踩过重装三次数据库才搞明白。现在列出来帮你省下三天调试时间。现象运行SELECT ... WHERE SITE (SELECT SITE FROM CUSTOMER WHERE CNAME美美)报错 “Subquery returns more than 1 row”子查询返回多于1行原因内层查询SELECT SITE FROM CUSTOMER WHERE CNAME美美找到了两条记录比如有两个“美美公司”。要求右边只能是一个值但你给了它两个。解决加LIMIT 1强制取第一个或用IN替代WHERE SITE IN (...)但更治本的是检查数据——为什么会有重名是否该用唯一编号如CNO而非名称做查找现象SELECT ... FROM (SELECT ... ) AS T报错 “Every derived table must have its own alias”每个派生表必须有自己的别名原因MySQL强制要求FROM后面的子查询必须用AS 别名命名哪怕你只是临时用一下。漏写AS T就会报这个错。解决死记硬背凡是在FROM后面出现的(...)后面必跟AS XXX。别名可以是任意合法名字比如AS TEMP、AS FILTERED_SALES。现象SELECT PCODE, (SELECT COUNT(*) FROM SALE WHERE SALE.PCODEPRODUCT.PCODE) ... FROM PRODUCT返回全是0或NULL原因外层PRODUCT表和内层SALE表的连接条件写错了。常见错误是写成SALE.PCODEPCODE没指定表名数据库不知道PCODE是指哪个表的可能默认为内层表导致条件失效。解决永远给字段加上表名前缀写成SALE.PCODE PRODUCT.PCODE。这是血泪经验——不加前缀90%的标量子查询都会逻辑错误。现象SELECT ... WHERE PCODE ! (SELECT PCODE FROM SALE)查不到任何“没被订购的产品”原因!和NULL在SQL里是“失联”关系。如果子查询返回NULL比如SALE表为空PCODE ! NULL的结果永远是UNKNOWN不是TRUE所以整行被过滤掉。正确做法是用NOT IN或NOT EXISTS。解决查“不存在”的场景无条件用NOT IN或NOT EXISTS。例如WHERE PCODE NOT IN (SELECT PCODE FROM SALE)。注意NOT IN如果子查询含NULL结果也会全空此时改用NOT EXISTS更安全实验第14题原写法!就是典型错误应改为NOT IN。现象嵌套查询执行极慢几秒没反应甚至卡死原因内层查询没有索引且在外层循环中被反复执行。比如标量子查询SELECT ..., (SELECT ...) FROM PRODUCT如果PRODUCT有1万行内层SELECT COUNT(*) FROM SALE...就会被执行1万次解决优先用JOIN代替标量子查询如用LEFT JOIN SALE ON ... GROUP BY替代SELECT (SELECT ...)如果必须用子查询确保内层WHERE条件字段如SALE.PCODE已建索引。这是性能玄学但新手起步就该建立意识。3. 先跑通第一个嵌套从“查同城客户”开始手把手敲出第一行有效SQL别急着背所有语法我们只聚焦实验第12题——它最简单、最直观且100%能跑通。跟着下面步骤你将亲手打出人生第一个真正有用的嵌套查询并理解每一部分在干什么。假设你已经安装好MySQL或类似数据库并成功导入了CPXS数据库含CUSTOMER、SALE、PRODUCT三张表。3.1 第一步确认数据先看看“美美公司”到底在哪儿在你的数据库客户端如MySQL Workbench、DBeaver或命令行里先执行这一句SELECT CNO, CNAME, SITE FROM CUSTOMER WHERE CNAME 美美;✅ 这不是嵌套是“探路”。目的是确认表里真有叫“美美”的客户避免拼写错误比如写成“美美公司”或“美美有限公司”它的SITE字段值是什么比如是“上海”还是“上海市”空格、标点都要一致它的CNO是多少后续可能用到。如果这句返回空说明数据里没有“美美”你需要换成实验里存在的客户名比如“华美”或“宏达”看CUSTOMER表实际数据。3.2 第二步写出内层查询单独验证它是否返回单个值把上一步查到的SITE值假设是“上海”填进去执行SELECT SITE FROM CUSTOMER WHERE CNAME 美美;✅ 这句必须只返回一行一列比如就一个“上海”。如果返回多行说明有重名按2.3节第一个坑处理如果返回空说明名字不对。只有这句稳了才能进下一步。3.3 第三步组装外层查询用内层结果做筛选条件现在把第二步的结果当作一个“已知答案”放进外层查询的WHERE条件里SELECT CNAME, TELE FROM CUSTOMER WHERE SITE 上海;✅ 这句是“模拟版”先手动把‘上海’写死确认逻辑对不对它应该列出所有地址是上海的客户名和电话。如果这句能跑说明外层结构没问题。3.4 第四步正式嵌套——把“上海”替换成子查询把第三步里的上海替换成第二步的整个查询记得加括号SELECT CNAME, TELE FROM CUSTOMER WHERE SITE (SELECT SITE FROM CUSTOMER WHERE CNAME 美美);✅ 这就是最终的嵌套查询执行它。你应该看到和第三步相同的结果所有上海客户但这次数据库是自己查出来的“上海”而不是你手动写的。 关键参数说明SELECT SITE FROM CUSTOMER WHERE CNAME 美美内层负责“找答案”必须返回单值WHERE SITE (...)外层负责“用答案”表示严格匹配单个值整个语句的逻辑链条先查美美在哪 → 得到“上海” → 再查所有地址是“上海”的客户。3.5 第五步举一反三改一个参数立刻得到新结果现在把美美换成另一个客户名比如宏达SELECT CNAME, TELE FROM CUSTOMER WHERE SITE (SELECT SITE FROM CUSTOMER WHERE CNAME 宏达);✅ 不用改任何其他地方只换名字就能立刻查出和“宏达”同城的所有客户。这就是嵌套查询的威力——参数化。你封装了一个逻辑“查同城客户”只需要改一个输入客户名就能复用无数次。以后写报表、做后台接口全靠这种思路。提示如果执行报错请立刻回到2.3节对照那5个坑逐一排查。90%的问题都出在内层返回多行、没加表名前缀、或用了!而不是NOT IN上。4. 统计函数和分组查询嵌套的“搭档”不是对手很多新手以为嵌套查询是“高阶技巧”得等学完所有基础才能碰。其实恰恰相反——它和COUNT、SUM、GROUP BY这些基础操作是天然搭档经常一起出场。实验里大量题目如第2、3、5题表面看是分组统计但它们正是嵌套查询的“前置训练”和“最佳拍档”。我们不把它当独立章节学而是直接看它怎么和嵌套配合发力。4.1 分组统计GROUP BY是“分堆”嵌套是“挑堆”先看实验第2题SELECT CNO, COUNT(PCODE) FROM SALE GROUP BY CNO HAVING COUNT(PCODE) 2;这句在做什么它先把订单表SALE按客户编号CNO“分堆”每堆是一个客户的所有订单然后对每堆数一数有多少个产品COUNT(PCODE)最后用HAVING把“堆里产品数2”的那些客户挑出来。✅GROUP BY解决的是“按什么维度分组”HAVING是对分组后的结果做筛选注意不是WHEREWHERE是分组前筛HAVING是分组后筛。现在如果需求升级“查出这些‘至少订了2种产品’的客户中谁的总订购量最大”这就需要嵌套了——外层要排序取最大内层先算出每个客户的总订购量SELECT CNO, TOTAL_QTY FROM ( SELECT CNO, SUM(OQUANTITY) AS TOTAL_QTY FROM SALE GROUP BY CNO HAVING COUNT(PCODE) 2 ) AS ACTIVE_CUSTOMERS ORDER BY TOTAL_QTY DESC LIMIT 1;✅ 解析内层括号里就是第2题的逻辑但加了SUM(OQUANTITY)计算总数量并起别名TOTAL_QTY外层把内层结果当一张新表ACTIVE_CUSTOMERS再对TOTAL_QTY降序排列取第一行。这就是典型的“分组嵌套”GROUP BY负责精细切分和聚合嵌套负责把聚合结果当数据再加工。4.2 统计函数COUNT/SUM/MAX/MIN是“计算器”嵌套是“调度员”实验第5题SELECT MAX(PRICE) FROM PRODUCT很简单就是查最高价。但如果你要“查出最高价对应的产品名称和编号”就不能只用MAX()了因为MAX()只返回值不返回整行。这时嵌套就来调度SELECT PCODE, PNAME, PRICE FROM PRODUCT WHERE PRICE (SELECT MAX(PRICE) FROM PRODUCT);✅ 这里MAX(PRICE)是内层的“计算器”它算出一个数字比如99.9外层的WHERE PRICE ...是“调度员”拿着这个数字去主表里找到所有价格等于它的产品注意可能有多个同价产品所以用而不是LIMIT 1。对比如果用ORDER BY PRICE DESC LIMIT 1只能取一个且无法保证是“所有最高价产品”。4.3 避坑HAVING 和 WHERE 的混淆是新手分组查询最大雷区提示这个坑几乎每个初学者都踩过而且很难自己发现。错误写法实验第4题原题SELECT SITE, COUNT(CNO) FROM CUSTOMER GROUP BY SITE HAVING SITE 上海; -- ❌ 错现象可能返回空或报错。原因HAVING是对分组后的结果即每个SITE对应的COUNT(CNO)做筛选但它不能用来筛选分组依据字段本身。SITE 上海应该在分组前就确定范围属于WHERE的职责。正确写法SELECT SITE, COUNT(CNO) FROM CUSTOMER WHERE SITE 上海 -- ✅ 放这里先筛出上海客户 GROUP BY SITE; -- 再按SITE分组此时SITE只有上海一个值✅ 记住口诀“WHERE 筛行GROUP BY 分堆HAVING 筛堆”。你想筛的是原始数据行如“只要上海的客户”用WHERE你想筛的是分组后的聚合结果如“只要客户数超过10的城市”用HAVING。另一个经典错误实验第6题原题SELECT COUNT(PCODE) FROM PRODUCT GROUP BY STOCKS HAVING STOCKS 500; -- ❌ 错现象返回多行每行一个COUNT(PCODE)但你要的是“库存500的产品总数”。原因GROUP BY STOCKS把产品按库存量分成了无数堆比如库存100一堆、200一堆…HAVING STOCKS500是在筛“库存量字段值500”的那些堆但每堆里COUNT(PCODE)是1因为每堆只有一种库存值结果就是一堆1。正确写法不需要分组SELECT COUNT(PCODE) FROM PRODUCT WHERE STOCKS 500; -- ✅ 直接筛行再统计总数✅ 总结当你要的是“满足某条件的记录总数”用WHERE COUNT当你要的是“按某字段分组后每组的统计值”才用GROUP BY COUNT。5. 连接查询JOIN和嵌套查询不是二选一而是“何时用哪个”的决策树新手常陷入一个误区学了JOIN就觉得嵌套是“过时写法”学了嵌套又觉得JOIN是“绕远路”。其实它们是数据库的左右手各有不可替代的场景。实验里第11、13题明显是JOIN第12、14题明显是嵌套但第13题如果写成嵌套也完全可行。关键不是哪个高级而是哪个更清晰、更安全、更易维护。5.1 一张表 vs 多张表先看数据在不在一张表里这是最根本的判断起点。数据在同一张表→ 优先考虑嵌套查询实验第12题查和“美美公司”同城的客户。所有信息客户名、地址都在CUSTOMER表里。你不需要拉其他表只需要“在本表里先查A再用A查B”。嵌套最直接。数据在不同张表→ 优先考虑JOIN实验第11题查由上海客户订购的订单要客户名、产品号、数量。客户信息在CUSTOMER表订单信息在SALE表。必须把两张表连起来JOIN是天选之子SELECT SALE.CNO, SALE.PCODE, CUSTOMER.CNAME, SALE.OQUANTITY FROM SALE INNER JOIN CUSTOMER ON SALE.CNO CUSTOMER.CNO WHERE CUSTOMER.SITE 上海 AND SALE.OQUANTITY 200;✅JOIN清晰表达了“关联关系”CNO是连接键且性能通常优于等价的嵌套因为数据库优化器对JOIN更友好。5.2 逻辑是“关联”还是“存在性判断”决定用 JOIN 还是 NOT IN/EXISTS这是第二个关键决策点。需要“关联出详细信息”如客户名、产品名、联系电话→ 用JOIN实验第13题查单价比A01高的产品还要显示产品编号、客户编号、数量。这些字段分散在PRODUCT和SALE表JOIN可以一次性拉出所有需要的列。只需要“判断是否存在”如“这个产品有没有被订过”“这个客户有没有下过单”→ 用NOT IN或NOT EXISTS实验第14题查“没被订购的产品”。你只关心“PCODE 是否在 SALE 表里出现过”不关心订单详情。用NOT IN最简洁SELECT PCODE, PNAME FROM PRODUCT WHERE PCODE NOT IN (SELECT PCODE FROM SALE);✅ 比LEFT JOIN ... WHERE SALE.PCODE IS NULL更易读且在某些情况下性能更好尤其当SALE表很大时NOT IN可能提前终止。5.3 性能与可读性权衡JOIN 更快嵌套更“自解释”性能角度现代数据库MySQL 8.0, PostgreSQL对JOIN的优化极其成熟同等逻辑下JOIN通常比等价嵌套快10%-50%。因为优化器能更好地估算数据分布、选择连接算法Hash Join, Merge Join。可读性角度嵌套查询像一篇短文逻辑是线性的“先做A再用A做B”。JOIN像一张关系图需要你脑补连接路径。对于复杂多表关联嵌套反而更清晰。例如查“订购了上海客户所购产品的其他客户”用嵌套可以分三步写-- 步骤1上海客户买了哪些产品 -- 步骤2哪些客户买了这些产品排除上海客户 -- 步骤3查这些客户的详细信息而JOIN版本可能需要三层JOIN加复杂ON条件一眼看不出主干。所以我的建议血泪经验新手起步优先用嵌套它逻辑直、报错明、调试易能让你100%理解自己在干什么项目上线逐步替换为JOIN当逻辑稳定、数据量上来后用EXPLAIN分析执行计划把高频查询换成JOIN永远把可读性放第一位如果一个嵌套查询你能在3秒内读懂它在做什么那就别为了“显得高级”硬改成JOIN。代码是写给人看的顺便让机器执行。6. 下一步学什么从“会写”到“写得好”的三步进阶路径你现在能跑通第一个嵌套查询能区分WHERE和HAVING能判断什么时候该用JOIN、什么时候该用NOT IN——这已经超过了80%刚入门的同学。但真正的数据库能力不在于会写多少种语法而在于面对一个新需求时能快速拆解、精准选型、写出健壮可维护的SQL。接下来我建议你按这个顺序花一周时间每天专注一个方向把基础打牢。6.1 第一步用好“执行计划”告别盲写1天别再靠猜和试错。所有主流数据库都提供EXPLAIN命令它能告诉你数据库打算怎么执行你的SQL。这是你和数据库对话的“翻译器”。怎么做在你写好的任何查询前加上EXPLAIN比如EXPLAIN SELECT CNAME, TELE FROM CUSTOMER WHERE SITE (SELECT SITE FROM CUSTOMER WHERE CNAME 美美);怎么看关键信息以MySQL为例type列ALL表示全表扫描慢ref或eq_ref表示走了索引好rows列预估扫描行数越小越好Extra列出现Using filesort或Using temporary是性能红灯。行动清单① 对实验里所有查询逐个加EXPLAIN记录type和rows② 给CUSTOMER.SITE和CUSTOMER.CNAME字段创建索引CREATE INDEX idx_site ON CUSTOMER(SITE); CREATE INDEX idx_cname ON CUSTOMER(CNAME);③ 再EXPLAIN对比rows是否大幅下降。你会发现加索引后原本扫1000行的查询可能只扫5行。这就是“让数据库飞起来”的第一步。6.2 第二步掌握窗口函数解锁“动态排名”“移动平均”2天COUNT、SUM是静态聚合只能给你一个总数。但业务中更多是“每个客户自己的销售额排名”“最近3个月的平均销量”。这就是窗口函数Window Function的领域它是SQL 2003标准MySQL 8.0、PostgreSQL、SQL Server 全支持。一个救命例子实验第3题是“每个客户订购数量总数”但如果要“每个客户订购数量总数并按金额从高到低排名”用传统GROUP BY 子查询会非常绕。用窗口函数一行搞定SELECT CNO, SUM(OQUANTITY) AS TOTAL_QTY, RANK() OVER (ORDER BY SUM(OQUANTITY) DESC) AS RANKING FROM SALE GROUP BY CNO;学习路径① 先掌握ROW_NUMBER(),RANK(),DENSE_RANK()三兄弟的区别重点看并列时的编号逻辑② 再学SUM() OVER (PARTITION BY ... ORDER BY ...)做分组内累计求和③ 最后练AVG() OVER (ORDER BY ... ROWS BETWEEN 2 PRECEDING AND CURRENT ROW)做移动平均。为什么推荐因为窗口函数是“嵌套查询的进化版”——它把“先分组再对每组排序/累计”的逻辑压缩进一个函数里代码更短性能更好且天然支持ORDER BY这是老式嵌套做不到的。6.3 第三步动手写一个“可复用的查询模板”固化你的方法论2天不要停留在“做题”。把你学到的模式封装成一个随时能抄的模板。我当年做的第一个模板就是“查同城客户”的增强版-- 【模板】查与指定客户同城的所有客户含防错、注释、可配置 SELECT c1.CNO AS TARGET_CNO, -- 目标客户编号 c1.CNAME AS TARGET_NAME, -- 目标客户名称 c2.CNO AS SAME_CITY_CNO, -- 同城客户编号 c2.CNAME AS SAME_CITY_NAME, -- 同城客户名称 c2.TELE AS SAME_CITY_TELE -- 同城客户电话 FROM CUSTOMER c1 INNER JOIN CUSTOMER c2 ON c1.SITE c2.SITE -- 核心同城即SITE相等 WHERE c1.CNAME 美美 -- ← 这里改成你要查的客户名 AND c2.CNAME ! 美美 -- 排除自己 AND c1.SITE IS NOT NULL -- 防NULL导致结果异常 AND c2.SITE IS NOT NULL;这个模板的价值有表别名c1,c2避免字段歧义有完整注释说明每行作用有防错逻辑IS NOT NULL有明确的修改提示← 这里改成...用JOIN实现比嵌套更高效且能同时拿到目标客户和同城客户的所有字段。你的任务① 把实验第13题查高价产品也写成一个带注释、可配置的模板把A01设为变量② 把第14题查未订购产品用NOT EXISTS重写并加入COALESCE处理可能的NULL③ 把这三个模板存成.sql文件命名为template_same_city.sql、template_high_price.sql、template_unordered.sql。从那以后我每次接到新需求第一反应不是打开编辑器狂敲而是翻出这几个模板复制、粘贴、改参数、加字段。真正的效率不是写得快而是不重复造轮子把80%的通用逻辑固化成肌肉记忆。希望帮到你。本文还有配套的精品资源点击获取