SQL 基础查询这事儿，看着简单，但真到了写复杂业务报表、排查慢查询、或者跟别人对数据口径的时候，才知道基础扎实有多重要。我见过不少人一开始 SKIP 了这部分，觉得SELECT * FROM table就完事儿了，结果后面遇到 NULL 值统计错了、分页排序乱了、GROUP BY 写出来的结果跟 Excel 里手工算的对不上，回头再来补课，反而走了不少弯路。这篇是“SQL 大师之路”系列的第五篇，咱们就把SELECT查询这层窗户纸彻底捅破，从最简单的单表查询讲起，把条件过滤、排序、分页、聚合分组这些基本功练扎实。内容不搞花活，全是能直接落地的东西，适合刚入门的朋友系统过一遍，也适合干了两年活但有些细节没吃透的朋友查漏补缺。
1. 内容整体设计与思路拆解
1.1 为什么单表查询才是真正的分水岭
很多人有个误区，觉得 SQL 难在 JOIN、难在子查询、难在窗口函数。但以我带人的经验来看，真正的分水岭恰恰是单表查询。JOIN 写错了大不了结果集变宽，但 WHERE 条件写错了，那是直接拿错误数据去做决策，影响的是真金白银。
单表查询的核心就三件事：取哪些行（过滤）、取哪些列（投影）、以什么顺序和粒度呈现（排序与分组）。这三件事搞明白了，后面学 JOIN、学子查询，本质上就是在单表查询的思维上叠加维度而已。我经常跟新人说，你把单表查询练到条件反射，看到任何一个查询需求，能在十秒内说出该用哪几个关键字，你就已经超过市面上大半的“SQL Boy”了。
1.2 这套学习路径背后的逻辑
我特意把内容按照“查询基本结构 → 条件过滤 → 排序分页 → 聚合分组”的顺序来安排，这个顺序是有讲究的。先让你会读查询语句，再让你能精确锁定数据行，然后让你把结果按商业逻辑排好序、切好页，最后才是把多条记录“折叠”成汇总统计。每一步都在给下一步打地基。
比如没有先讲好 WHERE，直接讲 GROUP BY，你根本看不懂为什么WHERE必须在GROUP BY之前执行；没有讲好 ORDER BY，分析聚合结果时就很难快速发现数据异常。这套路径走完，你至少能独立完成业务上 80% 的取数需求——报表统计、数据核对、临时分析、数据清洗前的探查，全都能覆盖。
1.3 准备一个可以反复折腾的实验环境
学 SQL 最重要的是动手。我建议你本地装一个 MySQL 8.x 或者 PostgreSQL 15+，这两个是当前最主流、资料也最多的开源数据库。如果你机器上啥都没有，用 Docker 起一个最快：
docker run --name sql-lab -e MYSQL_ROOT_PASSWORD=yourpass -p 3306:3306 -d mysql:8.0后面演示我都用 MySQL 语法，PostgreSQL 绝大多数场景兼容。为了让你能照着敲，我建立一个专门用于练习的示例库，包含一张用户表和一张订单表，数据量不大但足够把基础查询的各种情况都跑一遍。下面这一节我就带你把环境准备好，顺便把数据的“体感”建立起来。
2. 核心细节解析与实操要点
2.1 SELECT 语句的完整执行逻辑
先从最容易被忽视的说起——SQL 的书写顺序和它的执行顺序完全是两回事。这是新手最容易懵的地方。你写出来的语句是这个顺序：
SELECT 列 FROM 表 WHERE 行过滤 GROUP BY 分组 HAVING 组过滤 ORDER BY 排序 LIMIT 分页但数据库引擎实际执行的时候，顺序是这样的：
- 先定位 FROM 指定的表
- 再通过 WHERE 把整表数据过滤一遍
- 然后 GROUP BY 分组
- 接着 HAVING 对分组结果做过滤
- 之后 SELECT 计算你要的列和表达式
- 最后 ORDER BY 排序、LIMIT 截断
这个顺序搞不清楚，你会踩很多看似“玄学”的坑。最典型的就是：你想在 WHERE 里用 SELECT 里刚起的别名，结果报错“未知列”。原因很简单——WHERE 执行的时候，SELECT 还没开始算呢。这一类细节我会在后面结合例子反复提到，它就是通往“大师之路”的垫脚石。
2.2 WHERE 条件里的三个常见陷阱
先说 NULL 值。SQL 里的 NULL 不是 0，也不是空字符串，它代表“未知”。你用WHERE name = NULL查不到任何数据，因为 NULL 和任何值比较，结果都是“未知”，而不是 TRUE。想查 NULL 必须用IS NULL。这个坑我在实际工作中见过太多次了——统计“未填写手机号的用户”时，写WHERE phone != ''，结果把phone IS NULL的用户全漏掉了，数据对不上账，排查了半天。
再说字符串比较。MySQL 的默认排序规则下，字符串比较通常不区分大小写，但你要是在生产库里遇到区分大小写的排序规则，WHERE name = 'abc'和WHERE name = 'ABC'查出来的可能不一样。所以我建议在代码里保持大小写一致，别指望数据库帮你做转换。
还有日期过滤。新手最容易写WHERE create_time >= '2024-01-01' AND create_time <= '2024-12-31'，但create_time是带时分秒的，这样写会把 2024-12-31 当天所有记录漏掉一半。更稳妥的写法是：
WHERE create_time >= '2024-01-01 00:00:00' AND create_time < '2025-01-01 00:00:00'这个“左闭右开”的习惯，是数据开发老手和新手的一个明显分界线。
2.3 排序和分页里的性能暗坑
ORDER BY 看着简单，但有两个点值得注意。第一，如果你排序的字段没有索引，数据量大时会产生“文件排序”，体现在慢查询日志里就是Using filesort。第二，分页越往深处翻越慢，经典的LIMIT 1000000, 20会让数据库先读出一百多万行再扔掉，这是极大的浪费。解决方法是“延迟关联”或者基于上次查询的最后一条记录来做“游标分页”，这一点我在第四节会用实例演示。
2.4 聚合查询的执行细节
GROUP BY 会把多行压成一行，所以 SELECT 里能出现的列是有严格限制的。在标准 SQL 里，SELECT 的列必须是分组列或者聚合函数，否则语义上就不成立。MySQL 默认允许你写出“不合规”的查询，它会随机取一条非分组列的值——这个特性叫ONLY_FULL_GROUP_BY没开启时的宽松模式。很多新人就在这里翻车：同一个 SQL 在测试库跑出 A 结果，在生产库跑出 B 结果，原因就是两组数据库的这个 SQL 模式配置不一样。
我的建议是，把这个模式打开，让数据库帮你拦下不严谨的写法：
SET SESSION sql_mode = 'ONLY_FULL_GROUP_BY';看起来是给自己找麻烦，实际上是在培养肌肉记忆。
3. 实操过程与核心环节实现
3.1 快速搭建实验数据
为了让下面的演示可复现，先把环境准备好。我用 MySQL 8.0 作为演示环境，先创建库表：
CREATE DATABASE shop_demo CHARACTER SET utf8mb4; USE shop_demo; CREATE TABLE users ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50) NOT NULL, age INT, city VARCHAR(50), created_at DATETIME ); CREATE TABLE orders ( id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL, product_name VARCHAR(100), amount DECIMAL(10,2), order_date DATE, status TINYINT );插入一些有代表性的测试数据。这里我特意掺入了一些 NULL 和重复值，方便演示各种边界情况：
INSERT INTO users (name, age, city, created_at) VALUES ('张三', 25, '北京', '2024-01-03 10:00:00'), ('李四', NULL, '上海', '2024-02-15 14:30:00'), ('王五', 30, '北京', '2024-03-20 09:00:00'), ('赵六', NULL, NULL, '2024-04-10 20:15:00'), ('孙七', 28, '上海', '2024-05-01 08:00:00'), ('张三', 35, '广州', '2024-06-11 12:00:00'); INSERT INTO orders (user_id, product_name, amount, order_date, status) VALUES (1, '手机', 3999.00, '2024-01-05', 1), (1, '耳机', 299.00, '2024-01-20', 1), (2, '电脑', 6999.00, '2024-02-18', 2), (3, '手机', 3999.00, '2024-03-22', 1), (4, '键盘', 199.00, '2024-04-12', 3), (5, '显示器', 1299.00, '2024-05-03', 1), (5, '鼠标', 99.00, '2024-05-10', 2), (6, '手机', 3999.00, '2024-06-15', 1);注意，这里users表里我故意让“张三”出现了两次，模拟现实中“同名用户”的存在；李四和赵六的 age 是 NULL，赵六的 city 也是 NULL。这些数据，就是后续所有练习的“磨刀石”。
3.2 基础查询的完整练习手册
我先带你把最基本的 SELECT 过一遍。第一类，全表扫描：
SELECT * FROM users;日常工作中我极少用SELECT *，但在数据探查阶段，它是了解表结构的最快路径。拿到一张陌生表，先DESC table;看字段类型，再SELECT * FROM table LIMIT 50;肉眼扫一遍数据分布，这是标准动作。
接下来是精确投影：
SELECT name, age, city FROM users;这一步看着简单，但它是“只取所需列”的习惯起点。生产环境里大宽表动辄上百个字段，全查出来不仅浪费 IO，还会让网络传输变慢。能用 3 列解决的事，不要 SELECT *。
然后是别名：
SELECT name AS 用户姓名, age AS 年龄, city AS 城市 FROM users;AS是可省略的，但写上可读性更好。注意，中文别名虽然能用，但在复杂 SQL 中会给后续解析带来麻烦，项目里尽量用英文别名，展示层再做映射。
过滤条件这里多写几种，对比着看效果：
-- 等值与不等值 SELECT * FROM users WHERE city = '北京'; SELECT * FROM users WHERE age != 25; -- 范围 SELECT * FROM users WHERE age BETWEEN 25 AND 30; -- 集合匹配 SELECT * FROM users WHERE city IN ('北京', '上海'); -- 模糊匹配 SELECT * FROM users WHERE name LIKE '张%';重点看 LIKE。%匹配任意多个字符，_匹配单个字符。这里有个业务上的常见诉求：查“所有姓张的”。直接写LIKE '张%'结果也是对的。但如果数据里有姓“章”的同音不同字，就会被漏掉，这是业务口径问题，需要跟需求方确认清楚，不是 SQL 本身能解决的。
再说说模糊查询的性能问题。LIKE '%张'这种前置通配符写法，无法利用普通索引，一定会全表扫描。如果这个表有几百万行，这个查询就会把数据库 CPU 打满。真要处理这种场景，更合适的方案是引入全文索引或者专门的搜索引擎，而不是死磕 SQL。
去重是另一个高频小知识点：
SELECT DISTINCT city FROM users;但 DISTINCT 有它的适用边界。当你 SELECT 多列时，它是对“多列的组合”去重，而不是对某一列去重。这一点很多人用错。比如你想知道“一共有几个不同的城市”，上面那句没问题；但你要是SELECT DISTINCT name, city，你得到的是“同名同城”去重后的组合，不是“唯一城市列表”。业务上对不上的时候，先检查这里。
3.3 排序分页的实战演示
排序是查询的“最后一公里”，直接把结果按业务逻辑摆好。单列排序很简单：
SELECT name, age, city FROM users ORDER BY age DESC;多列排序才是真正体现思考深度的。比如“先按城市排，再按年龄从大到小排”：
SELECT name, age, city FROM users ORDER BY city ASC, age DESC;这里有个细节：ORDER BY可以写列名，也可以写 SELECT 里列的序号。比如ORDER BY 2, 3 DESC表示按第二列排完再按第三列排。知道有这么回事就行，代码里最好还是写明确的列名，否则后续别人改 SELECT 列表时，很容易把排序逻辑悄悄改坏。
NULL 值排序是个容易忽略的坑。MySQL 默认 NULL 在升序时排在最前面，降序时排在最后面。如果你想把 NULL 固定排最后，在 MySQL 里得这么写：
SELECT name, age FROM users ORDER BY ISNULL(age), age;这个需求很常见——“把年龄未知的人放最后，其余按年龄排”。
分页最标准的写法：
SELECT name, age, city FROM users ORDER BY id LIMIT 2 OFFSET 2;LIMIT 后面是“取多少行”，OFFSET 后面是“跳过多少行”。你也许见过LIMIT 2, 2的写法，那只是 OFFSET 在前、LIMIT 在后的简写形式，和新写法等价，但可读性差一些。我建议统一用LIMIT ... OFFSET ...风格。
深分页性能问题在这里给个完整解法。假设你要查第 50000 页，每页 20 条，最笨的写法：
SELECT * FROM orders ORDER BY id LIMIT 999980, 20;数据库得数出 999980 行再丢掉，这个操作越到后面越慢。可以改成“先定位到起点，再往后取”的延迟关联写法：
SELECT o.* FROM orders o JOIN (SELECT id FROM orders ORDER BY id LIMIT 999980, 20) t ON o.id = t.id;子查询先只取主键，因为主键走索引覆盖，扫描速度快很多，再用主键回表拿整行，整体效率会好一个量级。在订单表这种上千万行的场景下，这个优化往往能把几十秒的查询拉回几百毫秒。
更好用的方案是“游标分页”：
-- 假设上一次取到的最大的 id 是 160 SELECT * FROM orders WHERE id > 160 ORDER BY id LIMIT 20;这种方式不依赖 OFFSET，每页都是从头开始走索引，页数越深优势越明显。但它要求排序字段是唯一且单调的，通常就是主键。如果业务上有复杂排序条件，可以先按这个思路取到主键集合，再二次排序，实现成本也不算高。
3.4 聚合与分组：从“明细”到“洞察”
聚合函数是基础查询里最实用的部分，它把一堆行折叠成一行。我把最常用的聚合用法串一遍。
统计数量：
SELECT COUNT(*) FROM users; SELECT COUNT(age) FROM users;这个区别值得反复强调。COUNT(*)统计的是行数，不管某个字段是不是 NULL；COUNT(age)统计的是 age 字段非 NULL 的行数。
在刚才的数据里，COUNT(*)是 6，COUNT(age)是 4，因为李四和赵六的 age 是 NULL。如果你做用户数统计时用了COUNT(age)，数据就会莫名其妙变少，这是很多报表对不上账的根源。
求和与平均：
SELECT SUM(amount), AVG(amount) FROM orders; SELECT AVG(age) FROM users;注意 AVG 同样会忽略 NULL 行。如果你希望把 NULL 当作 0 参与计算，必须先COALESCE(age, 0)转换，否则平均数的“分母”大小会跟你预期不一致。这种细节，做数据审计时能救命。
分组统计是聚合查询里的重头戏：
SELECT city, COUNT(*) AS user_count, AVG(age) AS avg_age FROM users GROUP BY city;这张表里city的分布是：北京 2 人、上海 2 人、广州 1 人、NULL 1 人。GROUP BY 会把 NULL 也单独归成一个分组，这一个行为在不同数据库里一致，但很多新人没想到空值也会形成一组。
如果想只保留人数超过 1 的城市，用 HAVING：
SELECT city, COUNT(*) AS user_count FROM users GROUP BY city HAVING COUNT(*) > 1;HAVING 和 WHERE 的区别要刻进脑子里：WHERE 是在分组前过滤原始行，HAVING 是在分组后过滤分组结果。就像做菜，WHERE 是“选食材”，HAVING 是“选成品菜”。WHERE 能用索引加速，HAVING 只能等分组算完再过滤，所以能写在 WHERE 里的条件就不要放到 HAVING。
结合案例看一个稍有业务感的查询——统计订单状态为已完成（status = 1）的用户数，以及每个用户的订单总额，再筛选出消费超过 1000 的用户：
SELECT user_id, COUNT(*) AS order_count, SUM(amount) AS total_amount FROM orders WHERE status = 1 GROUP BY user_id HAVING SUM(amount) > 1000 ORDER BY total_amount DESC;这个查询同时用到了 WHERE、GROUP BY、HAVING、ORDER BY，且顺序完全符合前面说的执行逻辑。写完之后，可以自己默念一遍执行顺序：先整表扫描，然后筛出 status = 1 的记录，再按 user_id 分组，算每组的订单数和总额，接着过滤总额大于 1000 的分组，最后按总额从高到低排序。每一步都能跟数据对上，这个查询你才算真正吃透了。
4. 常见问题与排查技巧实录
基础查询代码量不大，但实际跑起来，问题一点不少。这里整理几个我工作中高频遇到的坑，以及对应的排查思路。
4.1 NULL 参与运算导致结果异常
有一回某同事统计“订单折扣率”，SQL 大致是：
SELECT order_id, discount / original_price AS rate FROM orders;结果出来的 rate 是空的，他以为是数据有问题，查了半天。真实原因很简单——有一批订单的 discount 字段是 NULL，任何数值跟 NULL 做四则运算，结果只能还是 NULL。数据库不会报错、不会告警，它就静悄悄地给你返回一个 NULL。
排查这类问题，先看字段是否有 NULL，用这种写法快速定位：
SELECT COUNT(*) AS total, COUNT(discount) AS has_discount FROM orders;如果total和has_discount数量不一致，就能确认 NULL 是元凶。处理方案是明确“无折扣”的语义：是当作 0 还是跳过这批订单。如果当作 0，就用COALESCE(discount, 0)；如果跳过，就在 WHERE 里加discount IS NOT NULL。这里没有标准答案，完全取决于业务口径，但不管选哪个，都要在代码里写出来，而不是靠运气。
4.2 分组后结果莫名其妙少了一部分
GROUP BY 写完，发现结果只显示部分分组，第一反应往往是“数据丢了”。其实大概率是 HAVING 过滤掉了你不想要的分组，或者 WHERE 在分组前就把数据筛掉了。排查思路是“逐步打开”——先去掉 HAVING 跑一遍，再去掉 WHERE 跑一遍，看结果分别在哪个环节发生了变化。这个习惯能帮你快速定位是数据源本身没有该分组，还是条件误伤。
另一个我常遇到的情况是“分组列没选全”。比如按city分组，但个别城市的数据里存在city名不同但实际同一城市的情况，比如“北京市”和“北京”，GROUP BY 会把它们分成两组。这属于数据质量问题，SQL 层面可以直接 CASE WHEN 做归类：
SELECT CASE WHEN city IN ('北京', '北京市') THEN '北京' ELSE city END AS city_group, COUNT(*) FROM users GROUP BY city_group;注意，这里 MySQL 允许在 GROUP BY 里用 SELECT 的别名，这是它的扩展语法，PostgreSQL 同样支持，但某些数据库可能不认。跨数据库写代码时，稳妥起见，把 CASE WHEN 完整地再写一遍到 GROUP BY 里。
4.3 排序结果跟预期不一致
ORDER BY 排序出问题，常见有三类。第一类是字符串排序的“字典序”问题，比如ORDER BY amount DESC，如果 amount 字段是 VARCHAR 类型，那3999会排在9999后面，因为字符串比较是一个字符一个字符比的——先比第一位，1 比 9 小，所以 199 反而在 999 前面。这不是 SQL 错了，是类型选错了。修复方案是改字段类型为 DECIMAL，或者在排序时做转换：
SELECT id, amount FROM orders ORDER BY CAST(amount AS DECIMAL(10,2)) DESC;第二类是大小写排序。不同排序规则下，大写字母和小写字母的先后顺序可能不同。同样的语句，在 Linux 上的 MySQL 和在 Windows 上的 MySQL，跑出来的结果可能顺序不一致。排查时先用SHOW VARIABLES LIKE 'collation%';确认库的排序规则。
第三类是“看起来没排序”。这就是典型的执行顺序问题——如果你同时用了 GROUP BY 和 ORDER BY，GROUP BY 执行在 ORDER BY 之前，而且当 SELECT 里既有分组列又有普通列时，MySQL 可能不会按你直觉中的顺序排。稳妥做法是：排序字段要么是分组列，要么是聚合函数的结果，例如：
SELECT city, COUNT(*) AS cnt FROM users GROUP BY city ORDER BY cnt DESC;这里的 ORDER BY cnt 是对聚合结果排序，语义明确，不会出幺蛾子。
4.4 条件过滤时“该有的数据”没查出来
你写了个查询，凭经验“肯定有数据”，结果返回空集。优先检查三件事。
第一，字符串里是否有不可见字符。比如从 Excel 粘贴过来的数据，某些单元格可能带了换行符或者空格，你WHERE name = '张三'查不到，可能实际存的是'张三 '。用SELECT name, LENGTH(name) FROM users WHERE name LIKE '张%';看一眼长度就知道了。
第二，日期字段的格式。MySQL 中 DATE、DATETIME、TIMESTAMP 的显示格式可能不同，但核心是别拿字符串去跟日期比较时用了错误的格式。最稳的写法是WHERE order_date = DATE('2024-01-05')，让数据库帮忙做类型转换，而不是依赖隐式转换。第三个常见场景是等值匹配时，字段里存在大小写或全半角差异。
遇到“查不出来”的问题，我的排查习惯是：先不加任何 WHERE，只SELECT * FROM 表 LIMIT 20;，把原始数据捞出来肉眼看一遍。很多时候答案一眼就能看出来，根本不用猜。
4.5 深分页查询越跑越慢
这个在前面讲过了，但我想再从排查的角度补充一个判断技巧。看到分页查询慢，先看执行计划：
EXPLAIN SELECT * FROM orders ORDER BY id LIMIT 999980, 20;如果type列是ALL，或者Extra列出现Using filesort，说明这条查询没办法有效利用索引。解决办法就是我前面说的延迟关联或游标分页。日常业务里，如果产品非要支持“跳转到第 N 页”，建议对页码做上限限制，比如最多翻到 1000 页，防止有人恶意刷全表。实际上绝大多数用户最多翻到几十页就不会再往下了，设计上完全可以限制死。
4.6 到底什么时候该用 DISTINCT，什么时候该用 GROUP BY
这两个功能在去重场景下很容易混。简单说，DISTINCT 是“对结果集去重”，GROUP BY 是“按列分组并聚合”。如果你只想看“有哪些城市”，用SELECT DISTINCT city FROM users;更直观。如果你想看“每个城市有多少人”，必须用 GROUP BY。如果你“去重之后还要配对统计”，GROUP BY 几乎是唯一选择。
另一个建议是：不要轻易在SELECT DISTINCT *这种写法上偷懒。它去重的是整行，一旦表结构新增字段，去重逻辑就悄悄变了。代码里明确写出要 DISTINCT 的列，既是对自己负责，也是给接手的人减少困惑。
5. 进一步扩展的方向
基础查询练完之后，下一步我建议按这个顺序往下走：先学会多表 JOIN，把两张表通过主外键关联起来，这是所有业务系统的核心数据模型；然后再学子查询，理解 EXISTS 和 IN 的差异；接着是窗口函数，它能在不折叠行的前提下做排名、累计、同比环比，是数据分析场景的利器。
在学习方法上，我给你一个自己一直在用的习惯：每学一个语法，不要只背例子，要把“执行顺序”在脑子里过一遍，然后用EXPLAIN验证一次执行计划。SQL 是一门实践性极强的语言，眼过千遍不如手过一遍。你把这篇文章里的每条 SQL 亲手敲一遍，再改改 WHERE、换换 GROUP BY 的列，很快就能找到手感。
最后分享一条我踩过很多次坑之后才悟出来的经验：写 SQL 之前，先花一分钟问清楚业务口径——NULL 怎么算、重复数据去不去、时间范围包不包含边界。口径定清楚了，SQL 写起来就很顺；口径模糊，越写越乱，最后还得返工。这不是技巧问题，是工作习惯问题，但恰恰是这种习惯，决定了你能不能从“会写 SQL”进阶到“写得一手好 SQL”。
