简介：这份PDF面向国家开放大学MySQL数据库应用课程的学习者与数据库初学者，聚焦实验训练2的数据查询操作，帮助梳理从单表字段查询到复杂嵌套查询的完整练习路径。内容以汽车用品网上商城为实验场景，覆盖多条件筛选、DISTINCT去重、ORDER BY排序、GROUP BY分组，以及COUNT、SUM、AVG、MAX、MIN等聚合函数的用法，并延伸至内连接、外连接、复合条件连接和IN、比较运算符、EXISTS等嵌套查询题型，每类实验均配有题目与分析思路。资源包共1个PDF文件，大小约1.75MB，便于下载后按实验模块查阅和对照练习。已有3339人学习，适合课堂实验跟做、SQL查询复习与查漏补缺，也可作为教师组织上机训练的参考材料。
1. 零基础也能上手：MySQL 数据查询到底在查什么
很多人第一次打开数据库客户端，看到左边一堆表名、右边一个空白输入框，脑子里冒出的第一个问题是：这东西跟 Excel 有什么区别？我在 Excel 里点筛选、点排序、拉一下求和，鼠标点几下就出来了，为什么还要敲一堆英文单词？
区别在于“问题变复杂的时候”。Excel 里筛一个条件很轻松，但如果你要问“每个用户今年的消费总额，按金额从高到低排，只留超过 500 的”，就得插辅助列、写公式、再手动排序，改一个条件全部重来。而 MySQL 里这类问题就是一句 SELECT 的事，改条件只需要改一个数字。数据查询操作，说白了就是用一套固定的句式，向数据库提出越来越复杂的问题，并让它把答案整理好还给你。
这份实验训练资料围绕的就是这套句式：从最简单的单表字段查询，一路走到多条件筛选、去重、排序、分组统计、多表连接、子查询和集合合并。它适合完全没写过 SQL、但需要跟数据打交道的新手——课程实验要做、工作里要查报表、面试要问，都绕不开。下面按“先跑通一条最简单的，再一层层加难度”的顺序带你走一遍。
2. 为什么值得先学查询：SQL 里性价比最高的那部分
2.1 查询是数据库的“输出口”，增量却最小
建表、改结构、配权限这些事，一个项目往往做一次就很久不动；而查询是每天都在发生的动作。运营要拉一份销量，产品要看用户活跃，开发排查线上问题，最后落到的都是 SELECT。也就是说，同样的学习时间，投在查询上被使用的频率最高。
更关键的是它的学习曲线很平。INSERT、UPDATE、DELETE 涉及数据安全，写错一行就把线上数据改了；而 SELECT 只读不写，哪怕写错了，最坏结果是报错或者查出一堆没用的行，删库跑路这种事跟你无关。对零基础的人来说，一个可以放心乱试的环境，比任何教程都重要。
这份实验训练的价值就在这里：它把查询拆成 19 个编号实验，每个实验只增加一个新东西——这次加个条件，下次加个排序，再下次加个分组。你不需要一次性理解整张 SQL 语法图，只要顺着编号往下做，每一步都比上一步多一点点。
2.2 先建立“一张表就是一个 Excel sheet”的直觉
新手最容易卡住的地方不是语法，而是不知道自己在查哪张表。资料里反复出现“商品表”“订单表”“用户表”“评论表”“购物车表”“订单明细表”“类别表”，这是一个典型的汽车用品网上商城的库结构。你可以在脑子里这样摆：
| 表 | 一行代表什么 | 关键列 |
|---|---|---|
| 商品表 | 一件在售商品 | 商品ID、商品名称、类别ID、价格、数量 |
| 用户表 | 一个注册会员 | 用户ID、用户名、创建日期 |
| 订单表 | 一次下单 | 订单ID、用户ID、订单总价、下单日期 |
| 评论表 | 一条评论 | 评论ID、用户ID、商品ID、评论内容 |
| 购物车表 | 某人加购的一件商品 | 用户ID、商品ID |
| 类别表 | 一个商品分类 | 类别ID、类别名称 |
有了这张对照，看到“查询商品名称为挡风玻璃的商品信息”，你就知道去商品表；看到“查询订单发出者的名字”，你就知道光有订单表不够，名字在用户表里，得把两张表接起来。新手 80% 的翻车不是语法写错，是表找错了。
2.3 第一个例子：三行跑出你的第一条查询
理论上不用讲太多，先动手。假设库已经建好、数据已经导入，打开 MySQL 命令行或者任意客户端，连上数据库后先确认自己在正确的库里：
-- 切换到实验用的数据库（库名以你自己的环境为准） USE shop_experiment; -- 看一眼这个库里有哪些表，确认表名没记错 SHOW TABLES;USE是“进哪个库”，SHOW TABLES是“这个库里有什么”。这两句不查出任何业务数据，但能避免后面一连串“表不存在”的报错。我第一次搭环境时就因为没切库，对着一个空库查了半天，报错信息翻来覆去看不懂，血泪经验。
接下来跑资料里的实验 2.1：查询商品名称为“挡风玻璃”的商品信息。
-- * 表示“这一行的所有列都给我” -- WHERE 后面是筛选条件，字符串要用单引号包起来 SELECT * FROM 商品表 WHERE 商品名称 = '挡风玻璃';拆开看三块：SELECT *决定“要哪些列”，FROM 商品表决定“从哪张表拿”，WHERE 商品名称 = '挡风玻璃'决定“只留哪些行”。SQL 查询的骨架就是这三段，后面所有复杂玩法都是往这三段里加东西，或者把三段套起来。
2.4 从一条到多条：WHERE 后面可以接几个条件
实验 2.2 要求“查询所有促销的价格小于 1000 的商品”。这里同时有两个条件：是否促销、价格是否小于 1000，用 AND 连起来。
-- AND 表示两个条件都要满足；数值不加引号，字符串才加 SELECT * FROM 商品表 WHERE 是否促销 = '是' AND 价格 < 1000;如果改成“促销的 或者 价格小于 1000 的”，就把 AND 换成 OR。新手在这里常犯的错是混用又不加括号，比如A OR B AND C，数据库会先算 AND 再算 OR，跟你脑子里的顺序不一定一致。只要一行里同时出现 AND 和 OR，就用括号把意图写死，这是最省事的自保手段。
比较运算符除了=、<，还有>、<=、>=、<>（不等于，也可以写!=）。字符串模糊匹配用LIKE，%代表任意多个字符：
-- 查所有名称里带“玻璃”两个字的商品，% 是通配符 SELECT 商品ID, 商品名称, 价格 FROM 商品表 WHERE 商品名称 LIKE '%玻璃%';注意这里我把*换成了具体列名。查全部列在探索阶段很方便，但真正写报表时建议只取需要的列——数据量一大，取回一堆用不上的字段纯属给自己添堵。
2.5 结果太脏？DISTINCT 和 ORDER BY 是两把扫帚
实验 2.3 问“哪些用户评论过商品 ID 为 1 的商品”。同一个人可以评论多次，直接查会得到重复的用户 ID，所以要加 DISTINCT。
-- DISTINCT 作用于它后面的整行列组合，重复的整行只保留一条 SELECT DISTINCT 用户ID FROM 评论表 WHERE 商品ID = 1;有个坑要提前说：DISTINCT 去的是“整行重复”，不是“某一列重复”。如果你写SELECT DISTINCT 用户ID, 评论内容，因为评论内容不同，同一个用户还是会冒出来好几行。想让一个用户只出现一次，就只选用户ID这一列。
实验 2.4 则是排序。查类别 ID 为 1 的商品，按商品 ID 降序：
-- DESC 是降序（大的在前），省略或写 ASC 就是升序 SELECT * FROM 商品表 WHERE 类别ID = 1 ORDER BY 商品ID DESC;ORDER BY也可以多列排序，写在前面的优先：ORDER BY 价格 DESC, 商品ID ASC意思是先按价格从高到低，价格相同的再按 ID 从小到大。另外排序是可以对文本用的，实验里“按用户名字排序”就是按字符顺序排。
3. 会算数才算入门：聚合函数与分组统计
3.1 五个聚合函数，先认清它们各自回答什么问题
到这一章，问题从“有哪些行”变成“这些行加起来是多少”。资料里实验 2.6 到 2.10 讲了五个函数，用一句话记住它们的用途：
| 函数 | 回答的问题 | 资料里的例子 |
|---|---|---|
| COUNT() | 有多少条 / 多少个 | 查询类别的数量、每天接单数 |
| SUM() | 加起来是多少 | 每天的销售额 |
| AVG() | 平均是多少 | 所有订单的平均销售金额 |
| MAX() | 最大的是谁 | 商品数量最大者、用户名最靠前者 |
| MIN() | 最小的是谁 | 商品中价格最低者 |
先跑最简单的 COUNT：
-- COUNT(*) 数的是行数；COUNT(列名) 数的是该列非空值的个数 SELECT COUNT(*) AS 类别总数 FROM 类别表;AS是给结果列起别名，不起也行，但结果表头会显示成COUNT(*)，看报表的人一脸问号。养成起别名的习惯，尤其是中文别名，交付时省掉一轮解释。
AVG 和 SUM 的用法一样，注意结果是小数：
-- 对订单总价这一列求平均；ROUND 保留两位小数，避免一长串浮点尾巴 SELECT ROUND(AVG(订单总价), 2) AS 平均订单金额 FROM 订单表;MAX 和 MIN 有个新手想不到的点：它们也能用在文本列上。资料里“查询所有用户按字母排序中名字最靠前者”就是用 MAX 取文本最大值，按字符编码顺序比较。这在中文环境下结果可能不符合直觉，但不报错，属于“能用但别乱用”的范畴。
3.2 GROUP BY：把“一个总数”拆成“每组一个数”
单用聚合函数得到的是全表一个数。加上 GROUP BY，就变成每个组一个数。实验 2.5 的第一个例子问“每个用户的消费总金额”：
-- 先按用户ID把订单分成一堆一堆，再对每堆的订单总价求和 SELECT 用户ID, SUM(订单总价) AS 消费总金额 FROM 订单表 GROUP BY 用户ID;执行顺序值得说清楚，它决定了你能写什么不能写什么：数据库先按 FROM 找到表，用 WHERE 过滤行，再用 GROUP BY 分组，然后对每组算聚合函数，最后才用 ORDER BY 排序。所以WHERE 里不能写聚合函数，想过滤“消费总额大于 1000 的用户”，得用 HAVING：
-- HAVING 在分组之后过滤，可以引用聚合结果；WHERE 在分组之前过滤，不行 SELECT 用户ID, SUM(订单总价) AS 消费总金额 FROM 订单表 GROUP BY 用户ID HAVING SUM(订单总价) > 1000 ORDER BY 消费总金额 DESC;资料 2.6 的第二个例子“每天的接单数”套路一样，只是分组列换成下单日期：
-- 按下单日期分组，每组数一下有多少订单 SELECT 下单日期, COUNT(*) AS 接单数 FROM 订单表 GROUP BY 下单日期 ORDER BY 下单日期;3.3 多列分组：分组依据可以不止一个
实验 2.5 的第二个例子“查询类别价格一样的各种商品数量总和”，分组依据是“同类别 + 同价格”这个组合，所以 GROUP BY 后面写两列：
-- 类别ID 和 价格 都相同的商品算一组，统计每组有多少件 SELECT 类别ID, 价格, COUNT(*) AS 商品数量 FROM 商品表 GROUP BY 类别ID, 价格 ORDER BY 类别ID, 价格;理解多列分组的关键是别把它想成“先按类别分，再在每类里按价格分”这种层级结构，它就是把这两列的组合值当成一个整体钥匙，(1, 88) 和 (1, 99) 是两把不同的钥匙，各开一个组。
还有一个必须记住的规则：SELECT 里出现的非聚合列，都应该出现在 GROUP BY 里。MySQL 在某些配置下允许你写不在 GROUP BY 里的列，它随便挑一行的值返回给你，不报错但结果没有意义——这类“不报错的错误”最伤人，因为你不盯着看根本发现不了。
3.4 一条查询里能塞多少东西
把前面学的拼起来，就是日常最常见的那种统计查询：
-- 查 2024 年之后下单、订单总价大于 50 的订单， -- 按用户汇总消费金额和订单数，只保留消费超过 500 的用户，按金额降序 SELECT 用户ID, COUNT(*) AS 订单数, SUM(订单总价) AS 消费总额, ROUND(AVG(订单总价), 2) AS 平均每单 FROM 订单表 WHERE 下单日期 >= '2024-01-01' AND 订单总价 > 50 GROUP BY 用户ID HAVING SUM(订单总价) > 500 ORDER BY 消费总额 DESC;一句里同时出现了 WHERE、GROUP BY、HAVING、ORDER BY，看着长，但按刚才的执行顺序一段一段读就通了：先筛行、再分组、再筛组、最后排序。你以后看到再复杂的统计 SQL，也基本是这个骨架的变形。
4. 数据分散在多张表：连接查询怎么接
4.1 内连接：只要两边都有的
实验 2.11 问“所有订单的发出者名字”。订单表里有用户ID，但没有名字；名字在用户表。这时要把两张表按用户ID 对上：
-- INNER JOIN 只保留两张表都能匹配上的行 SELECT 订单表.订单ID, 用户表.用户名, 订单表.订单总价 FROM 订单表 INNER JOIN 用户表 ON 订单表.用户ID = 用户表.用户ID;三个要点。第一，ON后面写的是连接条件，本质是在声明“这两张表的哪两列是同一个东西”。第二，列名前面加表名是为了消歧义，如果两张表都有用户ID这一列，不写表名数据库会报“列名有歧义”。第三，INNER可以省略，只写JOIN默认就是内连接。
用生活化的话讲：内连接像相亲，两边条件对上了才成一对，对不上的直接不出现。所以如果有个用户从没下过单，他不会出现在结果里。
实验 2.11 的第二个例子是购物车表连商品表，套路完全一样，只是连接键换成商品ID。
4.2 外连接：一边全要，另一边有就配、没有就留空
实验 2.12 问“列出所有用户 ID，以及他们的评论，如果有的话”。注意“所有用户”这个词——没评论过的用户也得出现，这就是外连接。
-- LEFT JOIN：左表（用户表）的行全部保留，右表没匹配上的填 NULL SELECT 用户表.用户ID, 评论表.评论内容 FROM 用户表 LEFT JOIN 评论表 ON 用户表.用户ID = 评论表.用户ID;左右怎么记？写在前面的表叫左表，它的行一个都不能少。资料里特意提醒“需将全部显示的列名写在 JOIN 语句左边”，说的就是这个。反过来用 RIGHT JOIN 也能实现同样效果，只是要把用户表挪到右边，实际写的时候几乎所有人都用 LEFT JOIN，可读性更好。
外连接有个特别容易翻车的点：如果你在 WHERE 里对右表的列加条件，比如WHERE 评论表.评论内容 LIKE '%好%'，那些 NULL 行会被过滤掉，LEFT JOIN 就悄悄退化成 INNER JOIN 了。想保留没评论的用户同时筛评论内容，条件得写在 ON 后面，或者额外加OR 评论表.评论内容 IS NULL。
4.3 复合条件连接：连接完再筛，或者边连边排
实验 2.13 的两个例子分别展示了“连接 + 过滤”和“连接 + 排序”：
-- 连接之后再筛：只要用户ID 为 1 的订单 SELECT 订单表.订单ID, 用户表.用户名, 订单表.订单总价 FROM 订单表 INNER JOIN 用户表 ON 订单表.用户ID = 用户表.用户ID WHERE 订单表.用户ID = 1; -- 连接之后排序：购物车里的商品按价格从低到高 SELECT 购物车表.用户ID, 商品表.商品名称, 商品表.价格 FROM 购物车表 INNER JOIN 商品表 ON 购物车表.商品ID = 商品表.商品ID ORDER BY 商品表.价格 ASC;这里有个性能上的常识，虽然零基础阶段不用深究，但早点知道有好处：能用 WHERE 提前把行数减下来的，就别等连接完再筛。表小的时候感觉不出来，等数据量上到几十万行，差别就明显了。
4.4 三张表也能连，但要一步一步来
新手看到需要三张表就慌，其实只是把 JOIN 写两遍：
-- 订单 → 订单明细 → 商品，拿到每个订单买了什么商品 SELECT 订单表.订单ID, 商品表.商品名称, 订单明细表.数量 FROM 订单表 INNER JOIN 订单明细表 ON 订单表.订单ID = 订单明细表.订单ID INNER JOIN 商品表 ON 订单明细表.商品ID = 商品表.商品ID;写多表连接的稳妥办法是一次只加一张表：先写两张表跑通，确认结果行数合理，再加第三个 JOIN。一口气写完五张表再调试，出错了你都不知道是哪一段断的。
5. 查询套查询：子查询与集合操作的避坑清单
5.1 子查询：把一个查询的结果当成另一个查询的条件
实验 2.14 问“订购商品 ID 为 1 的订单，是谁发出的”。分两步想：先在订单明细表里找出商品 ID 为 1 的订单 ID，再拿这些订单 ID 去订单表里找用户 ID。写成一条就是子查询：
-- 括号里的先算，算出来的订单ID集合供外层 IN 使用 SELECT 用户ID FROM 订单表 WHERE 订单ID IN ( SELECT 订单ID FROM 订单明细表 WHERE 商品ID = 1 );IN换成NOT IN就是“没买过这个商品的人”。但 NOT IN 有个著名的坑：如果子查询结果里含 NULL，整个 NOT IN 会一条都查不出来，因为“不等于 NULL”既不是真也不是假。稳妥写法是加一句WHERE 商品ID = 1 AND 订单ID IS NOT NULL，或者改用 NOT EXISTS。
实验 2.15 用的是比较运算符配子查询，子查询返回单个值时可以直接比：
-- 先算出全站平均订单金额，再找高于平均值的订单 SELECT 订单ID, 订单总价 FROM 订单表 WHERE 订单总价 > (SELECT AVG(订单总价) FROM 订单表);注意这里子查询返回的是一个数，所以用>没问题。如果子查询可能返回多行，就必须配ANY、ALL或者IN，否则数据库直接报“子查询返回多于一行”。
5.2 EXISTS、ANY、ALL：三个容易搞混的关键字
EXISTS只关心子查询有没有返回行，不关心返回的是什么，所以子查询里写SELECT 1就够了，写SELECT *也不会更慢（数据库会优化掉）：
-- 如果存在用户ID 为 100 的用户，就列出他的信息 SELECT * FROM 用户表 WHERE 用户ID = 100 AND EXISTS (SELECT 1 FROM 用户表 WHERE 用户ID = 100);ANY和ALL的区别用一句话记住：> ANY是“比最小的那个大就行”，> ALL是“比最大的那个还大”。资料里实验 2.17 和 2.18 就是这个对照。实际工作里这两个用得不多，但面试爱问，理解到这个程度够用了。
UNION是把两条 SELECT 的结果上下拼起来，默认去重；UNION ALL不去重，所以更快。只要你不介意重复行，优先用 UNION ALL：
-- 价格小于 5 的商品，加上类别 1 和 2 的商品，重复行只留一条 SELECT 商品ID, 商品名称 FROM 商品表 WHERE 价格 < 5 UNION SELECT 商品ID, 商品名称 FROM 商品表 WHERE 类别ID IN (1, 2);用 UNION 有个硬性要求：上下两条 SELECT 的列数必须一样，对应列的类型要能兼容，否则报错。
5.3 新手最容易踩的五个坑
坑一：忘了写 WHERE，全表数据一次性拉回本地。现象是客户端卡住、内存飙升；原因是少写或写错过滤条件；解决是养成习惯——敲完 SELECT 先把 WHERE 写上再去补列名，或者在客户端里给大表查询设行数上限。
坑二：WHERE 里用了聚合函数，报 “Invalid use of group function”。现象是语句执行不了；原因是聚合函数要等分组之后才有值，WHERE 阶段还没分组；解决办法是把条件挪到 HAVING 里，或者用子查询先算出聚合值再比较。
坑三：LEFT JOIN 结果和预期不符，没匹配的行消失了。现象是左表那些“没有对应记录”的行不见了；原因是对右表的列在 WHERE 里加了条件，把 NULL 行筛掉了；解决是把条件搬到 ON 后面，或者显式允许 NULL。
坑四：GROUP BY 漏写列，结果数值看着对但经不起核对。现象是不报错，但某个非聚合列的值来路不明；原因是 SELECT 里有列没进 GROUP BY，数据库随手取了组内某一行的值；解决是把所有非聚合列都补进 GROUP BY，或者对它们也套上聚合函数。
坑五：用 NOT IN 查“没有做过某事的人”，结果永远是空。现象是明明有数据却查出 0 行；原因是子查询结果里混进了 NULL；解决是子查询里加IS NOT NULL，或者换成NOT EXISTS。这个坑我踩过不止一次，每次都以为是数据问题，查半天才发现是 NULL 在作怪。
6. 往下走的路线：从做完这 19 个实验到真正会用
这 19 个实验做完，你已经覆盖了单表查询的全部常用形态和多表查询的主干。接下来怎么走，我给一条按顺序来的路线，不用贪多。
| 阶段 | 练什么 | 大概花多久 |
|---|---|---|
| 巩固 | 把 19 个实验不看答案重写一遍，尤其是 2.5、2.11、2.15 这三类 | 2～3 天 |
| 加难度 | 自己给自己出题：本月销量前 10 的商品、复购率、每个类别的平均客单价 | 1 周 |
| 补基础 | 窗口函数（ROW_NUMBER、RANK）、CASE WHEN、日期函数 | 1 周 |
| 碰性能 | 学会看 EXPLAIN，知道索引大概在解决什么问题 | 边用边学 |
巩固阶段别急着看新东西。我当时做完实验觉得自己会了，隔一周再写 GROUP BY 居然卡住，才发现是“跟着答案写”造成的幻觉。不看答案重写一遍，比重看三遍教程有用得多。
自测题可以这样设计：从资料里的商城库出发，逼自己用一句话描述需求，再翻译成 SQL。比如“查每个类别里价格最高的那件商品”——这句话里藏着分组、聚合、还要把聚合结果跟原表对上，写出来会自然用上子查询或者连接。写不出来不要紧，卡在哪一步就去翻对应章节，这比漫无目的地刷教程精准。
补基础的部分，窗口函数是性价比最高的下一个目标。它能解决“每组取第一名”这类 GROUP BY 干不了的活，而且语法结构和聚合函数很像，学起来不费力。CASE WHEN 则是把“是否促销”这种字段翻译成人话的必备工具，做报表几乎天天用。
最后说个习惯。我现在每次写带 GROUP BY 或者 JOIN 的查询，都强制走一遍流程：先用SELECT COUNT(*)看看涉及的行数量级，再写主体，跑完检查结果行数是不是在合理范围，最后才拿去给别人用。这个习惯是被一次“少写一个连接条件导致金额翻了三倍”的报表逼出来的，那次数字看着挺正常，是业务方自己核对时发现不对劲。数据库不会骗你，但它也不会提醒你问错了问题，只能靠自己多看一眼。
希望这份路线能帮你把这 19 个实验真正变成自己的东西。
本文还有配套的精品资源，点击获取
