单表查询SQL，是数据库开发里出现频率最高、也最容易翻车的基础操作。很多人写了两三年SQL，对付复杂JOIN头头是道，回头写一条SELECT * FROM table WHERE ...却依然踩空值、去重、分组这些坑。这篇文章不聊多表，只把单表查询从执行顺序、核心语法、空值清洗到慢SQL优化一层层剥开，顺便把面试里高频问到的去重和分组问题也一起讲透。不管你是刚接触SQL的新手，还是想系统补一遍基底的开发者，都可以跟着把单表查询里的“想当然”重新过一遍。
1. 单表查询的整体思路与执行顺序拆解
1.1 书写顺序藏在后面的执行顺序
初学SQL的人最大的误区，是以为数据库照着“SELECT→FROM→WHERE”的顺序执行。实际上SQL的书写顺序和执行顺序是两套完全不同的规则，这一点几乎决定了你能不能理解后面所有的坑。
标准的SQL逻辑执行顺序大致是：FROM→WHERE→GROUP BY→HAVING→SELECT→DISTINCT→ORDER BY→LIMIT。也就是说，数据库拿到一条查询语句后，先确定数据来自哪张表，再基于行做条件过滤，接着分组、聚合，最后才轮到投影列和排序。
这个顺序带来的直接后果是：WHERE里不能使用SELECT中定义的别名，HAVING里却可以使用聚合函数和SELECT的别名（有些数据库支持）。比如一上来就写WHERE 总价 > 100，但“总价”是SELECT price * num AS 总价里才定义的，执行到WHERE时这个别名根本不存在，必然报错。理解执行顺序不是考试背概念，而是排错和设计SQL的底层地图。
1.2 单表查询的本质：对结果集做三次裁剪
把一张表想象成二维表格：行是记录，列是字段。单表查询的本质，就是在这一张表上做三次裁剪——先用WHERE选择需要的行，再用SELECT选择需要的列，最后用GROUP BY把行归并成组（如果需要的话）。
很多看起来奇怪的行为都源于这三次裁剪的先后：DISTINCT发生在SELECT之后，所以它是对最终投影出来的列去重，而不是对原始行去重；ORDER BY发生在DISTINCT之后，因此你可以按SELECT中的别名排序；LIMIT发生在最后，所以它截断的是最终结果集。
我调试过很多别人的慢查询，看到问题下意识就会先问一句：“这句SQL的FROM到底是哪张表？过滤条件能不能在WHERE阶段就杀掉大部分行？”因为单表查询的优化空间，本质上就是减少进入下一阶段的数据量。WHERE干掉的行越多，后续排序、分组、分页的压力就越小。这个“先过滤、再变形”的思路，是单表查询优化的第一原则。
2. 单表查询核心语法实操与易错点
2.1 SELECT列选择：别让星号成为习惯
SELECT *在联调时很方便，但放到生产环境就是隐患。一是它会把不需要的字段也查出来，增加网络传输和内存开销；二是当表结构变更时，SELECT *可能导致程序拿到意料之外的列，接口字段错乱。更微妙的是，SELECT *会让优化器在某些情况下无法利用覆盖索引，明明索引里已经有足够的数据，非要回表再取一遍完整行。
正确做法是把需要的列名显式列出来。不要觉得写全列名费劲，现代IDE都有自动补全。如果表有几十个字段但只需要两三个，写出来不仅是性能需求，也是可读性需求：看到SQL第一眼就能知道这段逻辑关心哪些数据。我在代码评审时特别在意这个，一条长SQL如果满眼*.*，我基本会直接打回。
2.2 WHERE条件：三值逻辑和运算符优先级
WHERE最常见的坑，是拿=去和NULL比较。SQL里的逻辑判断是三值逻辑：真、假、未知。NULL参与的算术和比较运算结果都是未知，所以WHERE name = NULL永远为假，查不到任何数据。判断空值必须用IS NULL或IS NOT NULL，这是单表查询里最基础的语法点，但也是线上翻车率最高的点。
另一个容易忽略的是运算符优先级。AND的优先级高于OR，所以WHERE a = 1 OR b = 1 AND c = 1会被解析成a = 1 OR (b = 1 AND c = 1)，而不是你以为的(a = 1 OR b = 1) AND c = 1。这个坑很难通过报错暴露，因为SQL不会报错，只会悄悄返回错误结果。我的习惯是只要条件里同时出现AND/OR，就一律加括号，不给自己留任何理解偏差的空间。
2.3 DISTINCT去重：它到底去掉了什么
DISTINCT看着简单，实际暗藏一个关键语义：它会比较投影之后的所有列，只有当所有列的组合完全重复时才会被去重。比如SELECT DISTINCT name, age表示(name, age)这个组合完全一致才算重复，而不是只看name。
有人期望DISTINCT只对name去重、保留任意的age，这是做不到的。要实现“按某一列去重，其他列取特定值”的效果，需要借助GROUP BY加聚合函数，或者窗口函数。另外特别注意：DISTINCT会触发排序或哈希操作，在数据量大的单表上，它可能比你以为的慢得多。后面第3节会专门展开去重场景的选型。
2.4 ORDER BY与LIMIT：排序分页的正确姿势
ORDER BY可以和LIMIT配合，这在单表查询里非常常用，但也容易出两种问题。
第一种是排序字段存在重复值，导致分页结果不稳定。比如按create_time排序，同一秒可能有很多条记录，分页时数据库返回顺序不确定，第二页可能出现第一页看过的数据。解决办法是在排序字段后加一个唯一字段（通常是主键）作为次级排序：ORDER BY create_time, id。这样顺序就彻底确定了。
第二种是LIMIT两个参数的含义容易混淆。LIMIT offset, count表示跳过offset条，再取count条；LIMIT count OFFSET offset是同样的效果。很多人把顺序记反，一查就是半天。这里再记一遍：第一个参数是偏移量，第二个参数是返回行数。顺序不能反。
2.5 GROUP BY与HAVING：聚合分析的正确打开方式
GROUP BY是单表查询从“行级操作”转向“分组统计”的核心语法。写了GROUP BY name之后，每个name只保留一组，SELECT列表里能出现的普通列必须包含在GROUP BY中，否则在不同数据库里要么报错，要么返回的值不可预测。MySQL旧版本在未开启ONLY_FULL_GROUP_BY时允许随便查，这种“能用”其实是陷阱，换到新版或严格模式立刻翻车。
HAVING跟在GROUP BY后面，专门过滤分组条件，可以和聚合函数配合。比如统计每个类别的数量，只保留数量大于10的类别：SELECT category, COUNT(*) FROM product GROUP BY category HAVING COUNT(*) > 10。注意WHERE在分组前过滤行，HAVING在分组后过滤组，两者职责完全不同。这个知识点面试高频，后面第5节我再仔细对比。
3. 空值、去重与数据清洗的实战技巧
3.1 NULL不是空字符串，聚合函数的差异从这里开始
单表查询里最脏的数据往往不是乱值，而是NULL。在SQL语义里，NULL表示“未知”，空字符串''表示“有值但内容是空”，两者完全不同。查询“去除空值”时，不能只写WHERE col <> ''，因为NULL <> ''的结果是未知，不会被保留。正确写法是WHERE col IS NOT NULL AND col <> ''，必要的时候还可以加上TRIM(col) <> ''，把纯空格也清掉。
NULL对聚合函数的影响比很多人想的更大。COUNT(*)统计的是行数，COUNT(col)统计的是col列非空值的个数；SUM、AVG会自动忽略NULL，但如果你希望把NULL当成0参与计算，需要先用COALESCE(col, 0)处理。写报表SQL时最怕的就是聚合结果少了一截，最后定位发现是有几条NULL被静默忽略，数据对不上账。
3.2 单表去重的三种典型场景
去重在业务上经常有不同的含义，对应的SQL写法也完全不同。
第一种是完全重复行去重，直接SELECT DISTINCT * FROM table。这种情况适合处理外部导入的脏数据，整行所有字段都一样才去重。
第二种是按单列或多列组合去重，希望得到每个组合的唯一记录。可以用SELECT DISTINCT col1, col2，也可以用GROUP BY col1, col2。如果只想知道有哪些组合，两种写法结果几乎一样。
第三种是“同一组内保留最新记录”，这是最纠结的。比如一张订单明细表，同一个订单有多条记录，想按订单号去重、保留最新状态。单表查询里通常这样写：SELECT order_id, MAX(status), MAX(create_time) FROM orders GROUP BY order_id。如果还想保留整条的完整字段，就需要子查询或窗口函数配合，此时已经超出“纯单表”的简单范畴，但思路仍是先把组和排序逻辑搞清楚。
3.3 数据清洗中“去除空值”的实际写法
实际做数据清洗时，去除空值往往不是一个条件就完事，而是要同时处理列内NULL、空字符串和纯空格。一个比较稳妥的单表清洗查询模板是：
SELECT id, NULLIF(TRIM(user_name), '') AS user_name, COALESCE(user_age, 0) AS user_age FROM user_raw WHERE user_name IS NOT NULL AND TRIM(user_name) <> '';这段SQL的意思是：清洗时把纯空格统一转成NULL，再把NULL作为“缺失值”看待；年龄字段则把NULL转成0，方便后续计算。过滤条件放在WHERE里，先筛掉不合格的行，减少后续处理的数据量。如果你只是想把空值统一替换，COALESCE和NULLIF这两个函数几乎是必用的。它们不改变表结构，只在查询层面完成清洗，非常适合临时排查脏数据。
4. 单表查询性能优化与慢SQL识别
4.1 索引加速的核心逻辑
单表查询一旦慢下来，绝大多数时候是WHERE条件没法有效利用索引。索引的作用相当于书的目录，数据库通过B+树快速定位到符合条件的数据位置，避免整表扫描。判断一条查询是否走了索引，最直接的方式是执行EXPLAIN看执行计划。
EXPLAIN SELECT user_id, order_amount FROM orders WHERE order_status = 'paid';在返回的type字段里，const、ref、range都是比较好的索引访问方式，ALL则代表全表扫描，需要重点优化。对于单表查询，优化的核心就是让WHERE和ORDER BY涉及的列能走到索引，尤其是过滤性强的列（比如状态、时间、用户ID）优先建复合索引。
4.2 哪些写法会让索引失效
索引不是建了就一定有用，以下几类单表查询写法会让索引形同虚设：
第一类是对索引列进行函数运算。比如WHERE YEAR(create_time) = 2025，这会让索引失效，因为数据库必须先算出每行的年份才能比较。正确写法是WHERE create_time >= '2025-01-01' AND create_time < '2026-01-01'，把计算挪到等号右边。
第二类是隐式类型转换。如果索引列是字符串类型，查询条件却写成WHERE user_id = 123（没有引号），MySQL可能隐式把列转换成数字，导致索引失效。规则很简单：字符串列就写字符串字面量，加引号。
第三类是左模糊查询。WHERE name LIKE '%关键字'没法用索引，因为索引是按前缀排序的。反过来LIKE '关键字%'则可以走范围扫描。业务上如果不得不做左模糊，单表内只能接受全表扫描，或者引入全文索引，这属于另一个话题了。
4.3 深分页的优化思路
LIMIT 1000000, 20这种深分页是单表查询的经典性能杀手。数据库不是直接跳过100万行，而是从头扫描到100万行后再取20行，前面的计算全被浪费。我见过一张500万行的表，翻到第100页，查询耗时从几十毫秒涨到几秒，罪魁祸首就是深分页。
两种常见优化思路：一是延迟关联，先用子查询查出目标页的主键ID，再回表取完整数据：
SELECT a.* FROM orders a INNER JOIN ( SELECT id FROM orders WHERE status = 'paid' ORDER BY id LIMIT 1000000, 20 ) b ON a.id = b.id;二是基于游标的键集分页，利用上一页最后一条记录的主键继续往后取：
SELECT * FROM orders WHERE status = 'paid' AND id > last_seen_id ORDER BY id LIMIT 20;第二种方案适合前后翻页的应用场景，性能最好，但缺点是不能直接跳页。做业务时可以先问清楚产品到底需不需要“跳到第100万页”，大多数场景用“加载更多”替代深分页，对数据库友好得多。
4.4 用慢查询日志和EXPLAIN定位问题
单表查询出现性能问题，第一步不是改SQL，而是把慢SQL找出来。MySQL里可以通过慢查询日志配置来记录超过指定阈值的SQL，比如设定超过1秒的语句都记录到日志。线上环境建议把long_query_time设得尽量小，比如0.5秒，配合监控系统收集慢日志，定期分析TOP SQL。
拿到慢SQL后，套上EXPLAIN看执行计划。我通常按这个顺序排查：先看type是不是ALL，是就看能建哪些索引；再看possible_keys和key，确认优化器有没有选错索引；最后看rows，估算扫描行数是否合理。很多时候把一条SELECT的WHERE条件建个复合索引，扫描行数直接下降两个数量级，比费劲拆SQL更高效。
4.5 避免不必要的全表列返回
优化单表查询时，SELECT *同样会成为瓶颈。即使走索引，如果查询需要返回表中所有列，而索引本身不包含这些列，数据库就必须一条条回表取数据，增加大量随机I/O。反过来，只返回需要的列，有时可以构造“覆盖索引”，查询所需数据全在索引里，连回表都省了。
判断一条SQL是否覆盖索引，同样看EXPLAIN的Extra字段，出现Using index就是覆盖索引，说明只扫索引就拿到数据，速度极快。日常写单表查询，先想清楚业务真正需要哪些列，不要图省事一把梭。这既是性能优化，也是代码洁癖。
5. 单表查询常见问题与面试高频题速查
5.1 高频报错和排查思路
单表查询的报错集中在三类：列名不存在、GROUP BY不匹配、NULL比较错误。
Expression #1 of SELECT list is not in GROUP BY clause是MYSQL严格模式下的典型报错，意思是SELECT里的某个列不在GROUP BY里，结果集无法确定这一行该选哪条记录。解决办法要么把该列加入GROUP BY，要么包上聚合函数，要么用任意值函数（如果你确定业务上不需要精确值）。
Column 'xxx' cannot be null则通常写在INSERT/UPDATE场景，但查询阶段如果大量使用COALESCE把NULL转成0，也能规避后续统计的连带问题。平时排查问题时，先看报错信息指向的列，再用SELECT * FROM table LIMIT 10看一眼实际数据，基本能定位七八成问题。
还有一类是“查询结果和预期不符”。如果涉及NULL，先检查条件是否用了IS NULL；如果涉及去重，先确认DISTINCT是否作用于整行；如果涉及分组，先确认聚合函数是否忽略了NULL。这些点看似琐碎，却是实战中定位最久的坑。
5.2 WHERE和HAVING到底怎么分
面试题很喜欢问这个，实际上只要记住它们的执行阶段就能举一反三。
WHERE在分组前执行，不能直接使用聚合函数；HAVING在分组后执行，可以且通常需要配合聚合函数。比如查“单价大于100的商品”，用WHERE price > 100；查“总销量超过1000的商品”，必须GROUP BY goods_id HAVING SUM(quantity) > 1000。如果在HAVING里写price > 100，它不是不能运行，而是语义变成了“对分组后的结果再过滤”，和分组前过滤的效果可能一样，但性能更差，因为你让数据库先做无效分组再去过滤。所以能用WHERE过滤的，永远不要丢给HAVING。
5.3 GROUP BY去重和DISTINCT去重怎么选
两者都能去重，但有区别。DISTINCT更直观，适合小结果集的简单去重；GROUP BY适合在去重的同时计算聚合值，或者在去重时要控制“每组保留哪条记录”的复杂场景。
性能上，二者底层都可能用到排序或哈希，具体哪个快取决于数据和索引。如果只是求唯一组合，DISTINCT通常更合适；如果去重还要数次数、求总和，用GROUP BY是唯一合理选择。另外，DISTINCT不能和聚合函数直接用，比如SELECT DISTINCT SUM(x)结果是单个数字，不是你想的“按组去重求和”。这种写法基本是错用，应该写成SELECT SUM(x) ... GROUP BY ...。
5.4 写单表查询时的安全习惯
聊单表查询，还有一个绕不开的安全习惯：避免把外部输入直接拼接进SQL字符串。很多注入漏洞的根源，就是查询条件通过字符串拼接生成，攻击者能把传入值改写成额外SQL语句。正确的做法是使用参数化查询（绑定变量），让数据库把值当数据而不是代码处理。
示例对比：
-- 不推荐 SELECT * FROM users WHERE name = '${userInput}'; -- 推荐（伪代码，示意参数绑定） SELECT * FROM users WHERE name = ?; -- 随后绑定 userInput 为参数，而不是拼进SQL这个习惯和单表查询本身没有直接关系，但它影响的是所有查询的底线。无论ORM是否帮你处理了参数，自己写原生SQL时都要养成用占位符的习惯，不要图省事把变量塞进字符串。安全无小事，这个习惯应该刻进肌肉记忆。
6. 单表查询的长期经验沉淀
最后分享几点我写单表查询的长期体会。第一个体会是：先把业务翻译成“先取哪张表、再过滤哪些行、最后要哪些列”的三段论，再落笔写SQL。很多查询出错，不是语法问题，而是压根没想清楚自己要对数据做什么。第二个体会是：不要迷信复杂写法，能在一个WHERE里干掉大部分行，绝不放到HAVING或者应用层去干，越早过滤越高效。第三个体会是：每次写完查询，养成跑一次EXPLAIN的习惯，不用记住所有字段，只看type、rows、Extra这三个关键列，就能筛掉绝大多数潜在慢SQL。最后一个很小但很实用的建议：涉及到NULL或去重的查询，先在测试表里手动插入几条边界数据验证一下，再上生产。数据是会骗人的，你以为你写的去重是对的，可能只是当前数据碰巧没触发。单表查询虽然简单，把每一个细节都吃透，你写复杂SQL的底气会完全不一样。
