MySQL SQL100题：从入门到业务实战的刷题路线图

带过不少新人也接过很多想转行做数据分析的人的私信。每次被问到“SQL到底怎么入门”我的答案从来没变过找一份靠谱的MySQL SQL100道基础练习题老老实实刷完比看十篇教程都管用。这个判断听起来有点“土”但它是我这些年带人带出来的经验——SQL是练出来的手艺不是看出来的知识。100道题的量级刚好能覆盖从单表查询到窗口函数的完整链路又不会多到让人三天就放弃。这篇文章我会详细拆解一套“SQL100题”该怎么排、该怎么刷、会在哪里翻车以及刷完之后距离真实业务还差哪几步。1. 为什么我把“100道SQL练习题”当成新人标配很多人一上来就买大部头、刷源码、研究执行计划结果连一个带GROUP BY的查询都写得战战兢兢。这其实不是智商问题而是输入方式出了问题。SQL语法本身不复杂复杂的是把中文业务描述翻译成SQL逻辑。这种翻译能力只能靠大量题目喂出来100道题就是最低摄入量。1.1 100道题到底对应什么能力边界的清理我经常做一个类比学SQL就像学开车。交规是半天能背完的但真正让你敢上路的是驾校里反复练习的倒库、侧方位、坡起。SQL也一样SELECT、WHERE、JOIN这些关键字一节课就能讲完但没有足够的练习题你根本不知道它们什么时候会联手给你挖坑。100道题对应的大致能力边界如下前20题单表查询、过滤、排序、去重这是“能看懂数据”的基础。第21-40题聚合、分组、HAVING这是“能提炼数据”的分水岭。第41-60题多表JOIN、UNION这是“能关联数据”的关键。第61-80题子查询、EXISTS这是“能用逻辑表达复杂需求”的阶段。第81-100题窗口函数、日期处理、综合场景这是“能贴近真实业务”的临门一脚。对基础薄弱的人来说10到15天刷完是合理节奏。每天10道题每道题跑通验证比一天狂刷50道然后全忘干净要强得多。1.2 什么样的基础算“基础”练完能达到什么程度“基础练习题”里的“基础”指的是考点高频不是难度低。很多所谓的入门题恰恰会把NULL、去重、分组边界这些最容易被忽略的细节全部压进去。刷完这套题之后能达到什么程度以我带人的经验看最直接的效果是面对一个中小规模业务查询你能独立写出可用SQL而不是打开文档现查现拼。比如“统计每个地区最近30天下单超过3次的用户并输出他们的首单时间”这种典型的业务翻译题刷过百题的人通常会有一个明确的拆解路径。此时你还不需要懂复杂的索引调优也不需要会设计分库分表那些是后面的事但你已经具备了一个合格数据岗位最底层的执行能力。2. 一套能打的“SQL100题”应该怎么编排同样是100道题编排决定了训练效果。如果随便抓100个乱序题目做得越多越混乱。我建议按难度和主题严格分段每一段都服务一个明确目的。题号范围主题典型题型第1-20题单表查询、过滤、排序WHERE条件组合、ORDER BY、LIMIT、DISTINCT第21-40题聚合与分组COUNT、SUM、AVG、GROUP BY、HAVING第41-60题多表关联INNER JOIN、LEFT JOIN、UNION第61-80题子查询与EXISTS标量子查询、IN子查询、相关子查询第81-100题窗口函数与综合场景ROW_NUMBER、SUM() OVER、日期函数、综合业务题2.1 第1-20题单表查询、过滤和排序这个阶段的核心目标是把手练熟。不要觉得SELECT * FROM table太简单真正要练的是条件表达式的精确度。比如“查询订单表中未发货且金额大于100的订单按金额倒序只取前10条”这个看起来很基础的题目已经涉及比较运算符、逻辑连接、排序方向、LIMIT四个知识点。我建议大家在这个阶段刻意练习“用不同写法表达同一个查询”。同一个需求可以写WHERE status 1 AND amount 100也可以写WHERE status IN (1) AND amount NOT BETWEEN 0 AND 100。这种对比能帮你理解SQL的灵活性也为后面阅读别人代码铺路。SELECT order_id, customer_id, amount FROM orders WHERE status 1 AND amount 100 ORDER BY amount DESC LIMIT 10;写完之后去执行计划看rows扫描了多少行能帮你建立初步的性能直觉。2.2 第21-40题聚合、分组和HAVING这个阶段是很多人第一次“卡住”的地方。单表查询是线性的而分组是“折叠”的。你需要理解一旦写了GROUP BYSELECT里能出现的列就受到严格限制——要么是分组列要么是聚合函数。常见的过渡题型是“统计每个用户的订单数和总金额并筛掉订单数小于2的用户”。这个题需要两步思考先用GROUP BY完成统计再用HAVING完成筛选。很多人会把HAVING和WHERE搞混这正是这段训练的焦点。SELECT customer_id, COUNT(*) AS order_cnt, SUM(amount) AS total_amount FROM orders GROUP BY customer_id HAVING COUNT(*) 2;要特别注意HAVING的执行时机在分组之后所以它可以使用聚合结果而WHERE不能。同样的条件写WHERE COUNT(*) 2会直接报错因为WHERE处理的是原始行聚合还没发生。2.3 第41-60题多表JOIN和集合操作到了这个阶段才真正进入SQL的“灵魂地带”。多表关联的关键不是背JOIN语法而是搞清楚每一行是怎么匹配上的。我会让新人反复练习一个问题JOIN之后行数变多还是变少为什么比如“用户表”和“订单表”按用户ID关联如果一个用户有3个订单JOIN后这个用户就会出现3行。这个“行数膨胀”的理解至关重要——很多人漏数据、重复数据都是在这里栽的。SELECT u.user_id, u.name, o.order_id, o.amount FROM users u LEFT JOIN orders o ON u.user_id o.user_id;我建议这段训练里加入大量“左右表主从切换”的题目什么时候用LEFT JOIN、什么时候用INNER JOIN、什么时候用RIGHT JOIN但更建议翻转表顺序。还要练习UNION与UNION ALL的区别前者去重后者不回但后者在大数据量下性能更好。2.4 第61-80题子查询与EXISTS子查询是很多人从“熟练工”到“会思考”的过渡桥。它允许你把一个查询的结果当作另一个查询的输入这种嵌套思维是SQL进阶最核心的能力。练习这个阶段的题目我会特别推荐“找出从未下过单的用户”这类反直觉题。它可以写成NOT IN子查询也可以写成NOT EXISTS但两者的结果在NULL存在时完全不同这是极好的测试题。SELECT u.user_id, u.name FROM users u WHERE NOT EXISTS ( SELECT 1 FROM orders o WHERE o.user_id u.user_id );相关子查询看起来血统纯正但初学者经常在脑子里面模拟它的执行顺序模拟到崩溃。我的经验是不用强行在脑子里按行展开先靠结果对不对来验证理解再逐步把复杂度降下来。2.5 第81-100题窗口函数、日期处理和综合场景窗口函数是SQL中“看起来高不可攀实际天天在用”的能力。它和GROUP BY最大的区别是分组聚合会折叠行窗口函数不折叠行而是在每一行旁边开一扇“窗户”看整体。比如“按用户分组计算每个订单金额在用户所有订单中的排名”用窗口函数一行搞定。SELECT order_id, customer_id, amount, ROW_NUMBER() OVER (PARTITION BY customer_id ORDER BY amount DESC) AS rn FROM orders;日期处理也是综合题常客例如DATE_FORMAT、DATE_ADD、DATEDIFF它们支撑着“近30天活跃”“本周新增”这类运营前置需求。最后20题最好设计成多个小需求的组合体比如“统计上月每天的新客数并对比前月同期”这样把前面所有技能点串起来。3. 刷题过程中最容易翻车的五个“隐藏考点”刷题最怕的不是报错而是“查出来了但结果是错的”。运行不报错反而更难排查因为SQL不会告诉你逻辑错了。以下五个坑基本覆盖了百题练习里80%的翻车现场。3.1 NULL不参与比较运算NULL不是0也不是空字符串它是“未知”。所以凡是和NULL做比较的表达式结果都是“未知”而不是TRUE或FALSE。比如你想找出所有“不是VIP”的用户很自然会写WHERE is_vip 1。但如果有些行is_vip是NULL这些行会被过滤掉。正确写法要显式处理WHERE is_vip 1 OR is_vip IS NULL。这个坑在面试里几乎是必考也是练习里最常被忽略的细节。再比如COUNT(字段)和COUNT()的差别COUNT(字段)会跳过NULL行COUNT()会数所有行。这种差异在算总数时差之毫厘、谬以千里。3.2 GROUP BY与SELECT列的“受控关系”在默认开启ONLY_FULL_GROUP_BY的MySQL版本里SELECT后面的非聚合列必须出现在GROUP BY里。换句话说你不能在分组查询里随意SELECT一个既没分组也没聚合的字段。我见过很多新人在这条报错上卡很久明明统计出来了却不明白为什么报错。答案很简单当数据被折叠成组后组内其他列可能有多行取值数据库不知道该显示哪一个。这个问题不只是练习报错它背后是对分组语义的理解。3.3 隐式类型转换让索引失效查询条件里字段和值类型不一致时MySQL会做隐式转换。比如字符型的user_id列你用WHERE user_id 123456来查它可能在列上做转换导致索引失效走全表扫描。这个坑在练习数据量小时毫无体感因为100行全表扫描也是瞬间完成。但一旦换到线上百万行数据同一个写法可能从毫秒级变成秒级。所以从练习第一题开始就要养成“字段填写值和字段类型严格一致”的习惯。3.4 多表关联时ON条件远比WHERE条件“先到先得”LEFT JOIN中如果你把右表过滤条件写在WHERE里很可能把LEFT JOIN“降级”成INNER JOIN。因为LEFT JOIN先按ON产生结果集再用WHERE过滤过滤后右表没匹配上的NULL行就被删掉了。典型错误用法SELECT u.user_id, o.order_id FROM users u LEFT JOIN orders o ON u.user_id o.user_id WHERE o.amount 100; -- 会丢掉没下过单的用户正确做法是把右表条件放进ON子句SELECT u.user_id, o.order_id FROM users u LEFT JOIN orders o ON u.user_id o.user_id AND o.amount 100;这个差异很多人刷完100道题都没意识到但业务上会直接导致统计口径出错。3.5 LIMIT 10000,10 的分页性能隐患练习题里经常有“取第N到第M条”的需求常规答案是LIMIT offset, count。这个语法本身没错但offset越大MySQL需要扫描并跳过前面所有行性能越差。练习阶段我不会要求你做深度优化但要建立这个意识LIMIT 10000, 10不是“只读10条”而是“先读到10010条再丢弃10000条”。后面做真实分页接口时你早晚会面对这个问题的工程解法。4. 拿到一道题我是怎么带着新人一步步拆解的题目拆解能力才是刷题真正要练的核心。如果只是瞄一眼答案然后照着敲一遍那叫“打字练习”不叫“SQL练习”。我带着新人做一道题通常走四步翻译业务、跑通版本、多方案验证、看执行计划。4.1 先翻译业务再决定SQL关键字很多题目看起来是中文长句比如“查询最近30天每个城市下单金额排名前3的用户”。先别急着写代码把句子拆成主谓宾“每个城市”意味着GROUP BY city。“排名前3”意味着窗口函数RANK或ROW_NUMBER。“最近30天”意味着WHERE过滤日期。“下单金额”意味着SUM聚合。还没动手之前思路已经成型。我建议新人把这层翻译写在纸上能写出来再碰键盘。这个过程能大幅减少“写了删、删了写”的无效循环。4.2 写出第一个能跑版本不追求一步到位有人喜欢憋大招非要想清楚最优解再写。我的建议恰恰相反先写一个能跑出结果的版本哪怕中间用到了笨办法。原因很简单SQL是结果导向的先有一个正确结果垫底后面优化才有参照物。比如上面那道题你可以先用子查询算出每个人在城市内的排名再加一层查询做过滤。虽然两层嵌套看着笨但每一步都有清晰验证点。有了正确输出再去想能不能用窗口函数一次写出、能不能少一层子查询。4.3 用同一份数据验证几条等价写法SQL的特色是同一个需求有很多种写法。练习时我特别推崇“一题多写”因为每种写法的性能特征和可读性都不一样。写法适用场景注意事项JOIN数据来源是平铺关系注意关联列是否有重复子查询需要先聚合再关联子查询结果集别太大EXISTS只关心“有没有”性能好于IN结果不受NULL干扰IN集合比较语义直观集合含NULL时结果可能不符合直觉同一份数据用这两种方式跑结果一致才算过关。如果结果不一致恭喜你那才是最值得深挖的时刻通常是NULL或重复行在作祟。4.4 迭代写法时留意执行计划跑到后面几十题我会让新人顺手敲一下EXPLAIN。不用看得多深就看三个位置type是不是ALL、key有没有用上索引、rows大概扫了多少行。比如全表扫描type ALL数据量小没关系但你要知道它意味着什么。索引列上有函数操作key可能变成NULL。rows差10倍说明写法明显有性能差距。这些概念只有亲手看到才会变成自己的判断力而不是停留在教程里。5. 从“刷完100题”到“真正会用SQL”还差这三步很多人刷完题自我感觉良好一到业务场景就懵。这不是题白刷了而是中间缺了衔接动作。以我的经验从刷完题到真正上手至少要补上三件事。5.1 练习环境的搭建别只会在网页里写在线练习平台很方便但也容易让人养成“只要能跑通就行”的错觉。线下环境是另一个世界你要自己装MySQL、建库、导数据、处理连接问题。我建议至少在自己电脑上跑一次安装MySQL并确认服务可以启动。用命令行或客户端执行一条SELECT。导入一份现成的样例数据比如经典的员工或订单结构。这一步是为了让你习惯“SQL不只是在文本框里跑它背后是一个服务、一份数据、一套配置”。后面做真实项目遇到的第一个坑大概率就是环境问题。5.2 把题目改成“带业务条件的变体”练习题的题干通常很干净但业务需求是脏的。所以我常做一件事用同一道题改三四个业务条件。比如原题是“统计每个用户的订单数”我会改成“统计每个用户上个月有效订单数”“统计每个用户最近7天订单金额”“统计每个用户的首次订单日期”。条件一变过滤位置、日期函数、去重规则全都要跟着变这才是真正的“活学活用”。5.3 面试与实战最在意的不是语法而是数据意识面试官问SQL很少直接考语法更多是看你的数据意识拿到结果会不会交叉验证清不清楚NULL对统计的影响知不知道怎么发现脏数据。100道练习题能给你的是“操作熟练度”但“数据敏感度”需要在真实数据上继续磨。刷题结束之后我建议拿一份稍有不规整的模拟数据来做一个月度报表。数据里有重复行、有NULL、有类型错乱这种环境下你能写出来的SQL才算真正能用。6. 如果你想自己攒一套“SQL100题”这是我的组题清单有些朋友找不到合适的题库干脆想自己攒。这完全是可行的而且自己出题比刷题更能检验水平。我把自己常用的组题思路整理一下给想动手的人参考。6.1 题库素材从哪来通用三件套不需要特别复杂的数据集三张表就够用用户表、订单表、商品表。这几乎能覆盖所有核心考点。再配一张区域表或类目表就能扩展出很多业务条件题。关键是把数据造得“脏”一点刻意放一些重复用户、NULL金额、时间跨天的订单。这比干净数据更能训练真实业务能力。我的习惯是每张表控制在几百行既保证跑得够快又能肉眼验证结果对错。6.2 难度梯度与自检表自己出题最容易犯的毛病是难度分布失衡。我建议按532来分简单题50道中等题30道难题20道。简单题用来建立信心中等题用来强化核心考点难题用来查漏补缺和体验综合场景。6.3 学习笔记模板做题过程一定要留痕。我的记录模板包含五栏题号、题干、核心考点、我的SQL、备注/优化点。做完一道题花两分钟写清楚这五栏复习效率会翻几倍。很多时候你会发现过了半个月回头翻笔记“我的SQL”和“优化点”之间已经能看出巨大差距那就是进步的证据。我个人的习惯是允许查答案但不允许背答案更不允许不验证就抄。所有从题库里看到的写法我都要求自己在本地环境跑一遍确认输出符合预期再收录进笔记。这样积累下来的才是真正属于自己的SQL手感。