单表查询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的底气会完全不一样。