第3章 查询与SQL

第 3 章 · 查询与 SQL

本章要回答的三个问题：表里的数据怎么变成"上月各业务员销售额""哪些货快断供"这样的答案？点点鼠标的设计视图和手写 SQL 是什么关系，该学哪个？查询越跑越慢时，从哪里下手排查？

为什么会有这一章

建模完工的庆典还没结束，华彩商贸的第一个真实考验就来了：老板娘拿着手机走进来说，供应链那边催她报下个月的采购计划，要求按品类列出近三个月的销量、现有库存和缺口。如果按老办法，这又是三个工作簿加一下午的人工对表；在数据库的世界里，答案是一个查询——数据各归各位之后，提问变成了一件轻活。

查询是数据库给用户的最强回报：你负责说清楚要什么，引擎负责翻箱倒柜。而 Access 给这门手艺配了两套操作方式：图形化的查询设计视图适合入门与日常改改条件；SQL——也就是结构化查询语言——则是一层不受界面限制的完整能力。两套是同一件事的两副面孔，设计视图里每拖一条线，背后都自动生成一段 SQL，切换到 SQL 视图随时可看。本章两个面孔都教，学完你会发现它们互为放大器。

更深一层看，查询熟练度直接决定了这个库对业务的价值上限。表是仓库，查询才是柜台；没有人因为仓库整洁而付钱，人们付钱是为了柜台上的答案。

读完能解决什么

• 用选择查询完成筛选、排序、多表联接与分组汇总，覆盖八成日常统计口径；
• 在 SQL 视图里读懂并写出联接、聚合、子查询语句，摆脱设计视图的能力天花板；
• 掌握三类进阶武器：参数查询（一查多用）、交叉表（行转列报表底座）、动作查询（批量增删改）；
• 面对一个跑得慢的查询，能按固定套路定位瓶颈——是联接丢失了索引、条件里包了函数，还是嵌套层数失控；
• 知道哪些算术应该留给查询现算而不是存成字段，反过来哪些汇总值得落成冗余表换取速度。

各节怎么分工

学习曲线刻意安排为先易后难：先用设计视图建立直觉，再揭开 SQL 面纱，然后才有资格玩组合技，最后学会照顾它们的健康。另送一条贯穿全章的阅读建议：每学一种查询，都问自己"它存进去的是什么"——答案是问题本身而不是数据，这一句领悟会让你在后面避免九成误用。

先决条件

• 第 2 章的五步法已完成，库里躺着结构健康的表和启用参照完整性的关系；
• 对"订单明细"这类中间表的存在意义有体感（否则联接会显得突兀）；
• 数学上需要回忆起小学乘除法就够了——分组求和比想象中直白。

往下走到哪

查询的产出最终要交到使用者眼前。第 4 章把本章做好的各种统计挂到窗体按钮上、印到报表版式里，让不会用数据库的同事也能一键得到答案。另外记住 3.4 的诊断思路在窗体变慢时同样适用——慢病同源。

出发前再立一条本章的使用纪律：任何查询保存时都写一句备注式的名字说明口径（时间范围、含不含作废），并默认所有查询对象都是可复用的公共资产而非私人草稿。一旦放纵"新建查询 1、新建查询 2"的随手习惯，半年后导航窗格就成了无人敢删的地雷场——查询层同样需要 2.4 式的工程化约束，这是许多教程不会告诉你的下半句。

还有一条心智准备：SQL 部分初读会觉得"记不住这么多关键字"，其实不必背——四百个常用词里的核心骨架不超过十个，写两句自然就长在手上了；真正值得精读的是每条子句背后的执行次序，那是排错和优化的源头活水。