想要入门数据分析、后端开发、运维甚至只是想把报表做得灵活一点SQL 基础查询语句都是绕不开的第一关。我遇到过不少零基础的同学花一周把网上流传的“命令大全”抄了一遍结果面对一张真实的订单表时连“查询金额大于 100 的订单”都写得磕磕绊绊。这通常不是态度问题而是把 SQL 当英语单词背了没有把它当成一种“向数据要答案”的表达方式。这篇文章不准备给你一份只适合收藏的“大全”而是一份能照着练习、写完能跑、跑完能理解的 SQL 基础查询指南。我会从查询的本质讲起再到单表查询、条件筛选、分组聚合、多表关联、子查询最后给出一张我私藏的避坑清单。无论你之前完全没写过代码还是背过语法但不会用跟着这篇文章把每个例子在本地跑一遍都比死记五十条命令有用得多。1. 查询的本质SQL 不是背命令而是向数据库要答案1.1 数据表就是一张有纪律的 Excel 表格很多人第一次接触 SQL 会被术语吓到其实关系型数据库里最核心的东西就是“表”。你可以把表想象成一张被严格规范过的 Excel 工作表横向是一行一行的记录比如一个用户、一笔订单纵向是一列一列的字段比如用户姓名、订单金额、下单时间。但和 Excel 不同数据库里的每一列都有明确的“类型”。最常见的类型有三类数字类型比如订单金额文本类型比如用户昵称、手机号日期时间类型比如下单时间。写查询条件的时候必须用和字段类型匹配的方式去比较比如数字用数字比较文本要加单引号日期也有专门的写法。这个“类型意识”越早建立后面踩的坑就越少。表里的行是没有固定顺序的。你往 SQL Server、MySQL 或其他数据库里插入数据时记录按什么顺序存放由存储结构决定并不代表查询结果会自动按插入时间排序。所以永远不要依赖“看起来的顺序”想让结果有序必须显式地告诉数据库用哪一列、按什么方向排序。1.2 写查询前先回答“四问”零基础写 SQL 最常见的挣扎是一打开编辑器脑子一片空白不知道该写什么。我后来养成了一个习惯不管业务多复杂先问自己四个问题我要从哪张表拿数据对应FROM后面的表名。我要看到哪些列对应SELECT后面的列名或计算结果。我要对哪些行感兴趣对应WHERE后面的过滤条件。我要的是一行一行的明细还是一个汇总数字如果是汇总就需要GROUP BY和聚合函数。举个例子假设有一张订单表orders字段包括order_id、user_id、amount、created_at、status。领导问你“昨天下单、金额超过 200 的订单有哪些”这时四问的答案分别是表是orders需要的列是order_id、user_id、amount条件是created_at是昨天并且amount 200需求是明细不做汇总。于是查询很快就有了雏形先写SELECT ... FROM orders WHERE ...再回头补具体列和条件。你会发现SQL 语法虽然多但骨架永远是“从哪张表要什么过滤什么”。那些复杂语句无非是在这个骨架上加排序、分组、关联或子查询。1.3 “写”的顺序和“执行”的顺序不一样这是零基础最容易忽略、但影响极大的一点。一条查询语句你按键盘的顺序一般是SELECT、FROM、WHERE、GROUP BY、HAVING、ORDER BY、LIMIT。但数据库执行时顺序完全不同先确定数据来源FROM以及相关的JOIN再按条件过滤行WHERE然后是分组GROUP BY接着过滤分组HAVING之后才计算要展示的列SELECT再做排序ORDER BY最后限量LIMIT为什么要理解这个顺序因为很多报错都源于“提前使用了还没算出来的东西”。比如有人想在WHERE里写SELECT中定义的别名或者想直接用聚合函数过滤数据库就直接报错。理解了执行顺序你会明白WHERE阶段根本还没有“分组后的结果”自然不能在WHERE里用聚合函数聚合和别名必须等到SELECT阶段才产生所以排序时虽然能用别名但HAVING里能不能用还要看具体的数据库实现。把这张执行顺序图记在脑子里你后面看任何报错都会比原来快一倍。2. SELECT 和 FROM让第一条查询从“看得懂”到“真正会写”2.1 最小可用查询星号虽方便别让它变成习惯最简单的查询是SELECT * FROM users;它的意思是把users表里所有列、所有行都拿出来。星号代表“全部列”。练习阶段用SELECT *很爽能看到整张表的模样快速了解有哪些字段。但进入真实工作环境后我建议你尽量少用星号原因有两条。第一很多表的列数远超你的想象可能是几十列里面有大量你根本用不上的内部字段。用SELECT *会在网络上传输多余数据也会让结果表格变得非常难读。第二代码的可维护性差。如果你在代码里写死了SELECT *下次别人给表增加一列结果集就变了下游依然按旧字段位置解析的程序可能直接崩溃。正确的做法是只写本次需要的列。例如只要用户昵称和注册时间SELECT user_name, created_at FROM users;这样查询意图一目了然数据量也小。2.2 列名裁剪、改别名、去重查询列的时候除了原样输出还可以做三件事改名、计算、去重。改名用AS比如SELECT user_name AS 用户名, created_at AS 注册时间 FROM users;别小看别名在聚合查询和多表关联时列名可能叫count(*)或total_amount如果不用别名结果表里就会出现一个特别难看的列头。用AS给它一个清晰的名字后面ORDER BY、HAVING里引用也更方便。如果某个字段的值有很多重复可以加DISTINCT去重。比如想知道订单表里出现过哪些订单状态SELECT DISTINCT status FROM orders;DISTINCT会把所有不同的status值返回。它本质上是让数据库做一次“分组去重”数据量大的时候有一定消耗所以要克制不要一看到重复就想去重先想清楚业务上是否真的需要唯一值。聚合里的“去重计数”也很常见想统计有多少个用户下过单而不是有多少条订单可以写COUNT(DISTINCT user_id)。这和单纯COUNT(*)的含义完全不同。2.3 格式习惯分号、引号、大小写越早养成越好很多教程会忽略这些“小”细节但它们恰恰是新手反复报错的来源。分号是语句的结束符号。在一个数据库客户端里只执行一条语句时不写分号也能运行但命令行或脚本里多条语句连在一起时分号就是分割符。我的建议是每条 SQL 都习惯性加上分号固定动作能省掉很多不必要的报错。字符串和日期值必须用单引号包裹数字不需要。比如SELECT * FROM orders WHERE status 已完成; SELECT * FROM orders WHERE amount 100;如果把数字写成100数据库会尝试把文本转成数字大多数情况下能运行但没必要如果字段是日期类型你写成字符串也得保证格式能被数据库识别例如2024-01-01。SQL 关键字本身大小写都可以select、SELECT都能跑。但行业内普遍习惯把关键字大写把表名、列名写成小写或遵循原有命名这样一眼就能区分“语法”和“业务字段”。这条不强制但统一风格会让你的 SQL 更好读也方便别人 review。3. WHERE条件筛选才是 SQL 最核心的手艺3.1 运算符速查先记住这些基本够用WHERE后面跟的是“行过滤条件”每一行只要条件成立就会被保留。常用的运算符其实非常有限我用一张表整理给你运算符含义示例等于status 已完成或!不等于status ! 已取消/大于 / 小于amount 100/大于等于 / 小于等于amount 100BETWEEN ... AND ...在某个闭区间内amount BETWEEN 100 AND 200IN (...)在给定列表里status IN (已完成, 已发货)LIKE模糊匹配配合%_user_name LIKE 张%IS NULL/IS NOT NULL是否为 NULLremark IS NULL其中最容易出问题的是NULL。SQL 里的空值和空字符串是两回事NULL表示“这个值不存在”它不等于也不等于0更不等于另一个NULL。所以判断某个字段为空必须写字段 IS NULL不能写字段 NULL。我见过很多新手在这里反复翻车明明数据里就是空值却怎么都筛不出来原因就是 NULL永远不成立。3.2 组合条件AND、OR、NOT 的优先级一个条件往往不够于是要用逻辑运算符把多个条件组合起来。基本用法可以理解成AND两个条件必须同时成立OR至少一个条件成立NOT取反这里最大的坑是优先级。在很多编程语言里AND的优先级高于ORSQL 也一样。如果你写下SELECT * FROM orders WHERE status 已完成 OR status 已发货 AND amount 100;数据库会先算AND也就是status 已发货 AND amount 100再和status 已完成做OR。结果导致“已完成但金额很小”的订单也被捞出来了。这大概率不是你想要的。正确做法是给先执行的条件加括号SELECT * FROM orders WHERE (status 已完成 OR status 已发货) AND amount 100;我教过的同学里十个人至少有一个人在这里栽过跟头。记住一条原则只要AND、OR混在一起就用括号把每个“完整逻辑块”框起来不要跟数据库赌优先级。3.3 LIKE 和 NULL两个最典型的翻车点LIKE用得很普遍但很多新手不理解通配符的含义。常用两个符号%代表任意多个字符_代表任意一个字符。比如user_name LIKE 张%能匹配“张三”“张伟”“张”。user_name LIKE 张_只匹配“张三”“张伟”不能匹配三个字的“张无忌”。如果你要找姓张、名字只有两个字的人写张_想找所有昵称里带“花”的人写%花%。LIKE和不一样要求完全相等。数据库中文本列后面前后有多余空格时LIKE的匹配结果也可能跟直觉不一致。一般建议先看数据本身是不是有空格问题再决定用哪种方式。NULL的另一个坑出现在聚合和 WHERE 组合时。比如查询退款金额小于 50 的订单你写出SELECT * FROM orders WHERE refund_amount 50;如果表里有很多订单根本没有退款refund_amount是NULL那这些行会全部被过滤掉因为它们和 50 比较的结果是“未知”而不是“真”。若你想把“没退款”和“退款少于 50”都算进来就要额外加条件SELECT * FROM orders WHERE refund_amount 50 OR refund_amount IS NULL;这一条我不会展开太多但它在真实数据分析里极其常见值得你专门拿自己的数据反复试。4. 排序、限量、聚合从“看出明细”到“算出结论”4.1 ORDER BY别靠运气排序必须显式指定ORDER BY用来给结果排序默认是升序ASC需要降序就写DESC。比如按下单金额从高到低SELECT order_id, user_id, amount FROM orders WHERE status 已完成 ORDER BY amount DESC;如果金额相同的场景你想进一步按时间排序可以多个字段用逗号隔开ORDER BY amount DESC, created_at DESC;前一个字段相同才轮到后一个字段生效。要注意ORDER BY的执行顺序非常靠后所以它可以使用SELECT里定义的别名。比如SELECT user_id, COUNT(*) AS order_cnt FROM orders GROUP BY user_id ORDER BY order_cnt DESC;这里order_cnt是别名在排序阶段已经存在可以直接用。另一个提醒是ORDER BY一般也要写在LIMIT之前。很多人会把顺序写反数据库虽然可能不报错但逻辑上先排序后限量才符合直觉先决定要前多少名就要先把名次算出来。4.2 LIMIT只要前 N 行数据库里的“限量”LIMIT会截断查询结果只返回前 N 行。比如想看最新 10 条订单SELECT * FROM orders ORDER BY created_at DESC LIMIT 10;这里如果没有ORDER BY查询返回的“前 10 行”是哪一个数据库并不保证。真实工作中LIMIT通常和ORDER BY搭配使用单独用LIMIT没有业务意义除非你只是想快速探一眼表结构。很多数据库支持OFFSET用于跳过前面若干行从而实现分页。比如每页 20 条第 2 页应该跳过前 20 行SELECT * FROM orders ORDER BY created_at DESC LIMIT 20 OFFSET 20;需要说明的是不同数据库的限量语法不完全一样。MySQL、PostgreSQL、SQLite 用LIMITSQL Server 常用SELECT TOPOracle 的旧版本则要用ROWNUM或FETCH FIRST。写代码前先确认你的数据库类型不然照搬别人的语句会不兼容。4.3 聚合函数把 N 条记录算成一条结果聚合函数的特征是“多进一出”它把多行数据计算成一个值。最常用的五个COUNT计数SUM求和AVG平均值MAX最大值MIN最小值比如我想知道orders表里总共有多少条订单、总金额是多少、平均金额是多少SELECT COUNT(*) AS order_cnt, SUM(amount) AS total_amount, AVG(amount) AS avg_amount FROM orders;这样得到的是只有一行几个字段的汇总结果。这里有几个细节值得展开。第一COUNT(*)统计的是行数不管某一列是否为NULLCOUNT(列名)只统计该列“非空”的行数。两者结果可能不一样。第二AVG在计算时会自动忽略NULL值。比如退款金额有 100、NULL、200 三行AVG(refund_amount)会算(100200)/2而不是除以 3。如果你想对NULL有特定处理就需要先用COALESCE把空值替换成指定值。第三SUM遇到全NULL会返回NULL而不是 0。很多人一看结果是空白就懵了其实是数据本身没有非空值。4.4 GROUP BY分组统计聚合前的“切分”聚合函数单独用只能得到一张表的整体汇总。现实需求往往是“按某个维度看汇总”比如按订单状态统计订单数、按商品分类统计销售额。这就需要GROUP BY。举个例子统计每个用户的订单数和总金额SELECT user_id, COUNT(*) AS order_cnt, SUM(amount) AS total_amount FROM orders GROUP BY user_id;数据库的执行逻辑是先把所有订单按user_id分成若干组再对每一组分别做聚合。于是结果里每个user_id一行后面跟着它自己的订单数和总金额。关于GROUP BY新手最容易犯的错是分组查询的SELECT里写了既没有参与分组、也没有被聚合的列。比如SELECT user_id, order_id, COUNT(*) FROM orders GROUP BY user_id;order_id既不在GROUP BY里也不是聚合函数这在不同数据库里可能直接报错或返回一个随机值。逻辑上一组里可能有多条order_id数据库不知道该显示哪一条所以这种写法没意义。如果分组后还要继续过滤不能用WHERE要使用HAVING。因为WHERE是在分组之前过滤原始行而HAVING是在分组聚合之后过滤组。比如想找“订单数大于 5 的用户”SELECT user_id, COUNT(*) AS order_cnt FROM orders GROUP BY user_id HAVING COUNT(*) 5;你也可以把HAVING COUNT(*) 5理解成“在分组结果里做筛选”。如果换成了WHERE COUNT(*) 5数据库一看执行顺序WHERE阶段聚合函数还没有算出来就会直接报错。5. JOIN当数据被拆到两张表靠什么重新“黏”起来5.1 为什么表要拆开以及“粘合点”是什么真实的业务数据很少只存在一张表里。用户信息在users表订单明细在orders表商品在products表。如果所有字段都堆在一张表里同一个用户每下一单他的昵称、手机号、地址就要重复存一遍数据量又大又容易不一致。所以设计数据库时会用范式把数据拆到多张表再通过一个共同的字段把关系建立起来。这个共同的字段通常就是“谁是谁的”的关联键。最常见的关联方式有两种主键和外键。主键是一张表里唯一标识一行记录的字段比如users.user_id外键是另一张表里指向主键的字段比如orders.user_id指向users.user_id。当你要同时拿到“订单号”和“用户昵称”时不能凭空找昵称必须通过user_id把两张表按行对上。这个“对上”的操作在 SQL 里就是JOIN。5.2 INNER JOIN 和 LEFT JOIN 怎么选JOIN的语法核心是“左表 JOIN 右表 ON 关联条件”。ON 后面写的是两张表用什么字段匹配。最基础的是INNER JOIN也就是“内连接”。它的意思是只有两张表里关联字段能匹配上的行才会出现在结果里。比如要查订单和用户昵称SELECT orders.order_id, users.user_name FROM orders INNER JOIN users ON orders.user_id users.user_id;如果某个用户在用户表里不存在或某个订单的user_id为空这个订单就不会出现在结果里。你丢掉了“关联不上”的数据。LEFT JOIN则完全不同它以左表为基准左表的每一行都会保留在结果里右表匹配得上就带出对应字段匹配不上右表相关字段就是NULL。例如SELECT orders.order_id, users.user_name FROM orders LEFT JOIN users ON orders.user_id users.user_id;这样即使某个用户信息缺失订单本身依然会显示只是昵称是空。对于订单分析场景这通常更安全。选择哪种取决于你要不要保留“有一方缺失”的数据。想查“所有订单及其用户信息”用左连接想查“既存在订单、又存在用户的有效数据”用内连接。5.3 ON 条件和 WHERE 条件的区别这是多表查询里最容易出 bug 的地方。很多人以为ON和WHERE差不多其实它们在左连接里的作用截然不同。ON决定了两张表怎么匹配WHERE是在匹配完成后对结果集做过滤。对于LEFT JOIN如果把右表的过滤条件写在WHERE里左表即使匹配失败也会因为条件不满足被丢掉结果上左连接就变成内连接了。举个例子SELECT orders.order_id, users.user_name FROM orders LEFT JOIN users ON orders.user_id users.user_id AND users.city 上海;这个写法会保留所有订单只是只有上海用户才能被匹配出昵称非上海用户昵称为空。如果改成SELECT orders.order_id, users.user_name FROM orders LEFT JOIN users ON orders.user_id users.user_id WHERE users.city 上海;那非上海用户整行都不见了因为它们经过WHERE之后被过滤掉订单也看不到了。这两种结果的语义完全不同尤其在分析“订单覆盖率”时差别会直接决定结论。判断技巧其实很简单跟“匹配”相关的条件放ON跟“结果集过滤”相关的条件放WHERE。遇到LEFT JOIN优先把右表条件放进ON保住左表行。6. 子查询查询结果也能当作临时表继续查6.1 FROM 子查询先算一个结果再继续用子查询就是“查询里的查询”本质上是你把一段查询结果当成临时表继续做上层操作。最常见的用法是放在FROM后面称为派生表。比如你想找出“总下单金额超过 1000 的用户”SELECT user_id, total_amount FROM ( SELECT user_id, SUM(amount) AS total_amount FROM orders GROUP BY user_id ) AS user_order_summary WHERE total_amount 1000;内层查询先把每个用户的总金额算出来形成一张有user_id和total_amount的临时结果外层查询再对这张临时结果按条件筛选。这里有一个非常重要的细节子查询必须起一个别名示例里的user_order_summary否则某些数据库会直接报错就算不报错可读性也很差。你可以把别名理解成“给这段临时结果起个名字”方便外层引用。6.2 WHERE 子查询IN 和 EXISTS 的用法子查询也可以放在WHERE条件里。最典型的是IN后面跟一个子查询表示“只要这个字段的值出现在子查询结果里就算满足条件”。比如想找出“最近 7 天下过单的用户信息”SELECT user_id, user_name FROM users WHERE user_id IN ( SELECT user_id FROM orders WHERE created_at 2024-01-01 );这段逻辑非常接近自然语言从users表里找用户条件是这些用户的user_id出现在了子查询结果里。它比一次性把所有订单和用户都关联起来再DISTINCT更容易理解。另一种方式是EXISTS它不关心子查询返回什么值只关心“有没有这样的行存在”。例如SELECT user_id, user_name FROM users u WHERE EXISTS ( SELECT 1 FROM orders o WHERE o.user_id u.user_id );SELECT 1是 EXISTS 里的惯用写法因为条件只关心是否有一个匹配行不关心具体查哪些列。EXISTS在理解上稍微绕一点但在某些数据库里性能更好尤其是子查询结果很大的时候。6.3 子查询和 JOIN 怎么取舍同一个需求通常既可以用 JOIN又可以用子查询。比如前面“最近 7 天下单的用户”需求也可以写成SELECT DISTINCT u.user_id, u.user_name FROM users u INNER JOIN orders o ON u.user_id o.user_id WHERE o.created_at 2024-01-01;两种写法逻辑上等价选哪种主要看两点可读性和性能。我的建议是零基础阶段先把子查询和 JOIN 都试试理解它们是如何得到相同结果的。实际工作时先用结构最清晰、最不容易写错的写法查询慢了再用执行计划分析不要一开始就追求“高级优化”。还有一个值得注意的地方WHERE里的子查询通常不能直接引用外层查询的列除非你写的是关联子查询如上面的EXISTS版本。如果不小心出现了“列不存在”的报错先检查子查询是否和外层有正确的关联条件。7. 零基础最容易踩的 5 个错误以及我建议的学习路径7.1 一张“错误对照表”把报错先拦在门外以下五类错误是我带过的零基础同学里最高频的。列成表格方便你写查询时自查。错误写法问题原因正确思路SELECT * FROM orders GROUP BY user_id没写聚合字段非分组列无法确定显示哪一条只选分组列或聚合列WHERE amount MAX(amount)WHERE 阶段聚合函数还没计算用子查询或 HAVINGWHERE refund_amount NULLNULL 不能用等号判断用IS NULLON 和 WHERE 条件乱放导致左连接丢数据左表行被 WHERE 过滤掉右表过滤条件放 ON字段拼写错误、中英文引号混用语法或命名问题先检查字段名和引号类型这些错误一旦经历过一次就基本不会犯第二次。关键是报错之后别慌按照执行顺序倒着排查先看FROM里的表是否存在再看字段名是否属于对应表然后看条件值的数据类型最后看括号是否匹配。7.2 学习顺序建议不要一上来就背全量语法我见过很多人收藏各种“SQL 大全”但从第一页背到最后一页结果工作里只用得上其中十几种。更高效的做法是“按查询链路学”。第一步把单表查询练熟会写SELECT、FROM、WHERE、ORDER BY、LIMIT能按条件筛选明细数据。第二步学聚合和分组用GROUP BY和HAVING做汇总统计。第三步学多表关联理解主键、外键会写INNER JOIN和LEFT JOIN。第四步学子查询把复杂需求拆成“先算出中间表再继续查”。每一步都找个真实数据练习。没有现成数据集可以自己虚构一个小业务用户表、订单表、商品表插入几十条数据然后问自己一系列问题。比如“每个商品各卖了多少件”“哪些用户连续两天登录”“上个月销售额最高的商品是什么”。这些问题从简单到复杂能逼着你去组合各种 SQL 能力。7.3 我个人练习 SQL 时最受益的一个习惯最后分享一个对我自己帮助最大的习惯所有 SQL 写完后不要只看结果对不对而是从头在心里“朗读”一遍逻辑。比如写完SELECT user_id FROM orders WHERE amount 100 GROUP BY user_id HAVING COUNT(*) 3就要默念先确定订单表过滤金额大于 100 的订单再按用户分组然后只保留订单数大于 3 的用户最后输出这些用户的编号。一旦你能把一句 SQL 翻译成这样的流程图说明你才是真的懂了。凡是翻译卡住的地方就是你语法薄弱的地方也是你下一步需要专门补的地方。SQL 基础查询说来说去就是在跟一张张表对话。你不需要记住所有语法细节只要脑海里始终装着“表、行、列、条件、分组、关联”这几个核心概念再复杂的语句也能逐步拆解。把这些基础查询语句反复写到顺手后面的窗口函数、复杂嵌套、性能优化对你来说就只是加法题了。