写这篇总结的时候我手上一个用ADO访问数据库的小项目刚收尾。回头翻了翻这段时间的学习笔记发现SQL语句这块是最基础也最容易被轻视的部分。很多人学ADO、学数据库编程一上来就盯着Connection、Recordset这些对象去啃结果真到写业务逻辑的时候一条查询语句卡半天或者写出来的SQL在数据量稍微大一点之后慢得离谱。所以这篇总结我把SQL语句单独拎出来梳理一遍因为它才是整个数据库编程的地基ADO只是把SQL递到数据库面前的那双手。无论你是刚开始学数据库编程的新手还是用过ADO但总感觉语句写得不够利索的开发者这篇内容都能帮你把地基夯实。我自己的学习顺序是先把SQL写利索再去碰ADO那些对象回头来看这个顺序确实省了不少弯路。这篇总结不搞长篇大论的理论全部围绕实际写代码时会用到的核心语法展开配合我当时练习时反复踩过的坑给你一条能直接照着练的路径。1. 整体思路为什么先啃SQL再碰ADO1.1 SQL是数据库操作的语言ADO只是搬运工先搞清楚一个最基本的逻辑。你用ADO写程序访问数据库本质上是三件事建立连接、发送SQL命令、处理返回的结果。ADO的对象模型Connection、Command、Recordset解决的是“怎么把命令送过去”和“结果怎么接回来”而SQL语句解决的是“到底要数据库干什么”。一个不懂SQL的人去学ADO就好比你学会了怎么开车但完全看不懂导航说的“前方路口右转”——车开得再顺不知道该往哪走也白搭。我之前见过一个同事写的代码为了查出某个状态下的记录数先把整张表Load到Recordset里再用循环一条一条数。数据量小的时候没感觉表里塞了几十万条之后那界面的响应速度直接让人崩溃。后来改成一条SELECT COUNT(*) FROM 表 WHERE 状态有效瞬间出结果。这个对比基本说明了SQL水平的差距对程序性能的影响有多大。所以我的建议是先集中火力把SQL语句本身搞明白再去看ADO怎么用。这不是说ADO不重要而是说SQL是前置条件。1.2 学习SQL的正确路线从增删改查开始SQL的语法体系看起来很庞大但如果按实用频率去排序绝大部分业务代码里跑的都跳不出这几大门类查询SELECT、插入INSERT、更新UPDATE、删除DELETE以及配套的条件控制WHERE、排序ORDER BY、分组聚合GROUP BY / HAVING、多表关联JOIN和子查询。把这些东西掌握了你就已经能应付绝大多数开发场景了。我给自己定的练习路线很笨找一套常见业务场景比如学生选课、订单管理、商品库存把增删改查每一种操作都写一遍然后逐步往里面加条件、加排序、加统计、加多表关联。每加一个知识点对照执行结果去验证自己理解得对不对。这个阶段不碰任何代码就在数据库的查询工具里纯写SQL把语法本身的肌肉记忆先练出来。用查询工具练习有一个好处你能直接看到执行计划和返回结果写错了立刻就知道哪里有问题。而且因为不需要考虑程序代码的衔接可以把全部注意力放在SQL本身这对建立扎实的基础非常关键。2. SQL核心细节与实操要点2.1 查询与条件筛选WHERE的边界感要清晰SELECT是SQL里出场率最高的语句但很多人只停留在“SELECT 列 FROM 表”这个层面。实际业务里几乎每条查询都离不开WHERE条件而条件写得好不好直接决定了结果集是不是你要的以及查询跑得快不快。举一个我最常拿来举例的场景。假设有一张订单表你要查“最近30天内下单金额超过1000元的有效订单”。如果不假思索直接写SELECT * FROM 订单表 WHERE 下单时间 DATEADD(DAY, -30, GETDATE()) AND 金额 1000 AND 状态 有效这个写法本身没错但我见过不少人会写成WHERE 金额 1000 AND 状态 有效把时间条件漏了或者把时间条件写成下单时间 BETWEEN 2024-01-01 AND 2024-01-30这样的硬编码不做动态计算。前者查出来的数据范围不对后者到下个月代码就得改——这些都是WHERE条件“边界感”不清晰的表现。练习WHERE时我建议你刻意往这几个方向多加刁难自己的条件多条件组合AND和OR混用时必须加括号不然运算优先级会让你怀疑人生。范围判断BETWEEN是包含边界的如果你需要“大于等于起始值且小于结束值”那更适合用和组合。空值处理用IS NULL而不是 NULL这是一个新手最容易栽的坑。NULL和任何值做比较结果都是NULL也就是不成立所以WHERE 备注 NULL永远查不出数据。还有一个容易被忽略的点SELECT后面到底要不要写*。练习的时候随便写没事但到了实际项目里我强烈建议你把需要的列名一个个列出来。这不是洁癖而是实实在在的性能考量——你不需要的列也查出来会白白增加网络传输和内存开销。更重要的是程序代码里依赖列名时写明确列名能让接口更稳定表结构一变你马上就能感知到。2.2 排序与分页让结果有序可读ORDER BY看起来简单但也有些小细节值得注意。首先是排序方向ASC升序和DESC降序要分清默认是升序很多人忘了写ASC/DESC就拿到反着的顺序。其次是多列排序的优先级问题SELECT 姓名, 班级, 总分 FROM 学生成绩表 ORDER BY 班级, 总分 DESC这条语句的意思是先按班级升序排同一个班级内再按总分降序排。这个执行顺序符合直觉但当你写的列多了之后一定要自己心里有数哪一列是主导排序的。我之前就犯过把关键列写在后面的错误导致分组效果完全没出来看起来数据一团糟。如果涉及分页查询不同数据库写法不一样。SQL Server用的是OFFSET FETCHMySQL用的是LIMIT。比如SQL Server里查第11到20条数据SELECT 编号, 名称 FROM 商品表 ORDER BY 编号 OFFSET 10 ROWS FETCH NEXT 10 ROWS ONLY这里的OFFSET 10意味着跳过前面10条FETCH NEXT 10 ROWS ONLY取接下来10条。需要注意OFFSET FETCH必须搭配ORDER BY使用这是语法要求不排序就分页是不行的。当时我在练习时分页最容易犯的错是OFFSET算错。第二页的起始偏移应该是页码-1乘以每页条数不要拿着页码直接当偏移量用。这个错我犯过不止一次建议你拿小数据表亲手算一遍把偏移量的公式刻在脑子里。2.3 聚合统计与分组从明细数据到汇总信息业务报表里最常出现的就是“统计每个部门的平均工资”“按月份统计销售额”“找出订单数量前十的客户”这类需求全部离不开GROUP BY和聚合函数。常见的聚合函数有COUNT计数、SUM求和、AVG平均、MAX、MIN最大最小用法都很直观。但这里有一个核心规则你必须烂熟于心SELECT后面出现的非聚合列必须出现在GROUP BY里面。什么意思看这条SELECT 部门, AVG(工资) AS 平均工资 FROM 员工表 GROUP BY 部门“部门”是非聚合列所以它必须出现在GROUP BY中。如果你想在结果里同时显示员工姓名和部门平均工资抱歉这办不到——因为每个部门的平均工资只有一条汇总值而你有多名员工他们对应不上。这个规则违反之后数据库会直接报错但如果你用的一些老版本数据库或者某些特殊的查询模式可能不报错却返回莫名其妙的结果那更让人头疼。GROUP BY的难点是条件去哪写的判断。WHERE和HAVING都有筛选功能区别在于WHERE在分组前筛原始行HAVING在分组后筛组。如果你想查“2024年平均工资超过5000的部门”必须先先用WHERE把2024年的数据筛出来再分组求平均值最后用HAVING过滤掉平均工资不足5000的部门SELECT 部门, AVG(工资) AS 平均工资 FROM 员工表 WHERE 入职年份 2024 GROUP BY 部门 HAVING AVG(工资) 5000这个执行顺序我一开始老搞混后来用一句话记住WHERE管的是“哪些行能进来参与分组”HAVING管的是“哪些组能出现在结果里”。2.4 多表连接与子查询让分散的数据产生关联现实中的业务数据几乎不会放在一张表里订单和客户分开、文章和作者分开、商品和分类分开这是为了减少数据冗余也就是常说的范式化设计。所以要把这些分散的数据重新拼在一起看就需要用到JOIN。我最常用的是INNER JOIN和LEFT JOIN它们的区别用一句话说清INNER JOIN只保留两边能匹配上的数据LEFT JOIN保留左表全部数据右表能匹配上的就填值匹配不上显示NULL。举个例子订单表里有客户编号客户表里有客户名称。你想查所有订单和对应的客户名SELECT 订单表.订单编号, 客户表.客户名称 FROM 订单表 INNER JOIN 客户表 ON 订单表.客户编号 客户表.客户编号如果有一笔订单对应的客户信息被误删了INNER JOIN就会把这个订单漏掉而LEFT JOIN能让订单依然显示出来只是客户名称是NULL。这个差异在统计场景里影响很大比如“统计每笔订单及对应客户”你肯定不希望因为客户资料异常而让订单凭空消失所以左连接在报表场景里用得更多。练习多表连接时建议你从两表连接开始熟练之后再加第三张表。三张表连接容易出的问题是JOIN顺序混乱或者ON条件写错列导致笛卡尔积爆炸——结果集的条数变成各表条数的乘积数据量翻着倍地涨查询慢到怀疑人生。子查询就是嵌套在另一个查询里的查询它可以用在WHERE、FROM、SELECT等位置。我常用的场景是“先算出一个范围再作为主查询的筛选条件”。比如“查出比平均工资高的员工”SELECT 姓名, 工资 FROM 员工表 WHERE 工资 (SELECT AVG(工资) FROM 员工表)这种写法先查出一个标量值再拿去和每一行比较逻辑很清楚。子查询的一个坑是如果子查询返回了多行数据你只能搭配IN、EXISTS这类操作符不能直接用来和单值比较。我刚练的时候总在这里翻车报错信息提示“子查询返回了超过1个值”才意识到自己忘了这个限制。2.5 数据修改INSERT、UPDATE、DELETE的注意事项增删改这三类语句在面试和日常开发里都要写但它们有一个共同原则操作范围一定要控制好。少了WHERE的UPDATE和DELETE会把整张表的数据全改掉或全删掉——这在生产环境里属于灾难性事故。INSERT的常见写法有两种一种是带列名的插入INSERT INTO 员工表 (姓名, 部门, 工资) VALUES (张三, 技术部, 8000)另一种是从另一张表查出来的结果直接插入适合做数据迁移或备份INSERT INTO 员工备份表 (姓名, 部门, 工资) SELECT 姓名, 部门, 工资 FROM 员工表 WHERE 状态 离职无论哪种列名和值必须严格一一对应。少一个列、多一个值都会报错我刚学的时候经常因为数据类型不匹配折腾半天——往数值列塞字符串往日期列塞文本数据库那边直接甩一个转换失败的错误回来。UPDATE和DELETE的危险之处在于它们的“无差别攻击”比如DELETE FROM 员工表这条语句会清空整张表。怎么样才能只删掉指定的人加上WHEREDELETE FROM 员工表 WHERE 员工编号 42即便是更新一个字段我也建议你在生产环境里先看一眼WHERE条件覆盖的范围。写UPDATE之前先跑一条相同条件的SELECT确认你要更新的行数符合预期再做更新。这个习惯我用了几条血泪教训才养成现在已经成为我写数据变更逻辑的默认动作。3. 一个案例串起SQL核心语法从需求到落地3.1 设计一张成绩表把语法都串起来光学不练假把式。我给自己设计过一个学生成绩管理的练习场景整个练完一遍之后对SQL的整体把握一下子就立体了。这里也拆给你看看。先建三张表学生表学号、姓名、班级、课程表课程编号、课程名称、学分、成绩表学号、课程编号、成绩。成绩表通过学号和课程编号与学生表、课程表建立关联这就是典型的三表结构。练习的第一步是把基本数据插进去。我准备了五个学生、三门课程、若干条成绩记录然后开始从易到难地写各种查询。这个阶段不用管什么优化、索引之类的概念就是纯语法练习。3.2 从单表查询到多表统计逐条写出核心SQL下面是当时我练的一组有代表性的查询也是我从“会写SQL”到“能顺手写SQL”的分水岭。第一个是查出每个学生的选课数量SELECT 学号, COUNT(*) AS 选课数量 FROM 成绩表 GROUP BY 学号第二个是查出每门课程的平均成绩并按平均成绩降序排列SELECT 课程编号, AVG(成绩) AS 平均成绩 FROM 成绩表 GROUP BY 课程编号 ORDER BY 平均成绩 DESC第三个是带上了三表连接查出学生的姓名、课程名称和成绩SELECT 学生表.姓名, 课程表.课程名称, 成绩表.成绩 FROM 成绩表 INNER JOIN 学生表 ON 成绩表.学号 学生表.学号 INNER JOIN 课程表 ON 成绩表.课程编号 课程表.课程编号这个查询把三张表的关联做出来了逻辑是成绩表作为中间桥梁一边连学生表拿姓名一边连课程表拿课程名称。练到这里多表关联的基本套路就形成了。第四个是统计每个班级的平均分并且只保留平均分大于80的班级SELECT 学生表.班级, AVG(成绩表.成绩) AS 班级平均分 FROM 成绩表 INNER JOIN 学生表 ON 成绩表.学号 学生表.学号 GROUP BY 学生表.班级 HAVING AVG(成绩表.成绩) 80这个练习把连接、分组、聚合、过滤全部串在了一起是我觉得最具综合性的一条。当时我专门把这条语句的执行顺序写在笔记本上先连接两张表形成临时结果集再按班级分组接着对每组求平均分然后用HAVING过滤掉平均分不足80的组最后把需要的列展示出来。3.3 理解SQL的执行顺序这是调优的第一课就在练这些语句的过程中我慢慢发现了一个特别重要的事SQL里语句的书写顺序和它的实际执行顺序不是一回事。从书写上你是先写SELECT再写FROM、WHERE、GROUP BY、HAVING、ORDER BY但数据库执行的时候顺序是这样的FROM确定要读取哪张表WHERE过滤掉不满足条件的行GROUP BY按指定列进行分组HAVING过滤掉不满足条件的分组SELECT计算要返回的列ORDER BY对最终结果排序这个执行顺序解释了为什么WHERE里不能用SELECT里定义的别名——因为SELECT还没执行别名根本不存在。比如SELECT 工资 * 1.1 AS 新工资 FROM 员工表 WHERE 新工资 5000是错的数据库压根不认识“新工资”这个别名得写成WHERE 工资 * 1.1 5000才行。理解这个顺序对排查问题帮助极大。有时候你发现一条语句返回的结果和预期不符按执行顺序一步步倒推基本就能定位是过滤时机问题WHERE和HAVING用错了还是执行顺序认知有偏差。4. 常见问题与排查技巧实录4.1 入门阶段最容易犯的五个错误我把周围朋友和自己在练习中反复出现的错误整理了一个速查清单每一条都有真实翻车背景建议你写SQL时对照着自查用判断NULL在WHERE里写列名 NULL结果永远查不出数据必须用IS NULL。字符串少了引号在SQL里字符串必须用单引号包起来而且如果字符串本身包含单引号需要用两个单引号转义比如WHERE 姓名 OBrien。WHERE与HAVING不分忘记WHERE筛行、HAVING筛组这个原则往往查出来的汇总数据莫名其妙地多了或少了。聚合列混用不使用GROUP BY把非聚合列和聚合函数一起SELECT又不加GROUP BY报错或者结果不明确。OFF SET分页算错第二页的起始偏移应该是(页面索引-1)×每页条数很多人直接拿页号当偏移查出来的数据永远是前几页。这些大多属于“会者不难”的问题但架不住它们出现的频率实在太高。我在练习阶段给自己定了个规矩每条SQL写完习惯性检查一遍这几个位置——NULL判断、引号闭合、聚合列是否分组、WHERE和HAVING的位置能省下大量的排查时间。4.2 SELECT之外ADO调用SQL时的特有坑既然标题里带了ADO编程这里我先把SQL层面和ADO直接相关的几个问题说透。你在数据库工具里把SQL写对了不代表往ADO代码里一搬就万事大吉有两个坑是ADO环境下特别容易踩的。第一个是参数化查询的问题。之前我在某公司做一个小工具的时候图省事直接拼SQL字符串比如string sql SELECT * FROM 用户表 WHERE 姓名 用户名 ;这种做法最大的风险是注入漏洞——用户名里如果包含 OR 11 --这样的内容整个查询的逻辑就被改写了。更稳妥的做法是使用参数化查询把用户输入当作参数传进去而不是拼进SQL字符串里。ADO里有Command对象配合Parameters集合来实现这一点虽然代码量会多一些但安全和稳定性的提升是绝对值得的。在学习阶段就把参数化养成习惯比以后线上出了事故再回头补课要划算得多。第二个是SQL语句中字符串内的单引号问题。ADO里用SQL字符串时文本内的单引号需要转义为两个单引号比如要查OBrien这个人在SQL里就必须写成OBrien。代码里如果你是用字符串拼接的方式处理这个转义很容易被忽略导致运行时抛SQL语法错误。这个问题非常隐蔽因为数据库管理工具里直接执行SQL时你可能刚好写对了而代码里经过一层拼接就可能出问题。4.3 排查思路从执行计划的视角找问题遇到SQL执行慢的情况不要急着去改代码先在数据库里跑一下这条语句的“执行计划”。执行计划就是数据库告诉你它打算怎么执行你这条SQL先读哪张表、怎么关联、用没用索引、有没有全表扫描。以前我发现一条分页查询随着数据量增大越来越慢打开执行计划一看排序操作占了大头而且没有走索引。原因是我排序的列没建索引导致数据库把整张表的数据都读出来后做了一次昂贵的排序操作。后来给排序列加上索引查询速度提升了好几个数量级。这个问题的教训是SQL慢不一定是你写得不对也可能只是索引缺失或者表设计不合理。但反过来说如果你SQL写法本身有问题比如关联条件不明确导致的笛卡尔积再好的索引也救不了你。所以排查顺序建议先看SQL语义对不对再看执行计划最后才动代码或加索引。写在最后的学习建议这篇总结写到这里SQL语句的核心内容基本都覆盖到了。我个人在实践中的一个体会是SQL这门技能看十遍教程不如亲手写一遍。建议你找一套自己熟悉的数据场景按我上面的练习路线从单表查询一直练到多表统计每一条语句都实际跑一遍看看结果和你想的是否一致。不一致的地方就是你理解还有偏差的地方那才是真正涨知识的地方。还有一个小技巧分享给大家平时在程序代码里写SQL之前先在数据库查询工具里把SQL单独跑通确认结果正确后再搬到代码里。这样能帮你把SQL本身的错误和程序代码的错误隔离开排查问题的时候会清爽很多。这个习惯我一直用到现在大大减少了两边同时出问题时的混乱局面。SQL这块地基打牢之后下一步就可以放心去啃ADO编程了。等我把ADO那部分笔记也整理完再接着写这个系列的第二篇。 
长河君 · 2026/10/15 5:08:08 · 阅读 1.2k SQL语句是ADO数据库编程的地基：从增删改查到性能优化
写这篇总结的时候我手上一个用ADO访问数据库的小项目刚收尾。回头翻了翻这段时间的学习笔记发现SQL语句这块是最基础也最容易被轻视的部分。很多人学ADO、学数据库编程一上来就盯着Connection、Recordset这些对象去啃结果真到写业务逻辑的时候一条查询语句卡半天或者写出来的SQL在数据量稍微大一点之后慢得离谱。所以这篇总结我把SQL语句单独拎出来梳理一遍因为它才是整个数据库编程的地基ADO只是把SQL递到数据库面前的那双手。无论你是刚开始学数据库编程的新手还是用过ADO但总感觉语句写得不够利索的开发者这篇内容都能帮你把地基夯实。我自己的学习顺序是先把SQL写利索再去碰ADO那些对象回头来看这个顺序确实省了不少弯路。这篇总结不搞长篇大论的理论全部围绕实际写代码时会用到的核心语法展开配合我当时练习时反复踩过的坑给你一条能直接照着练的路径。1. 整体思路为什么先啃SQL再碰ADO1.1 SQL是数据库操作的语言ADO只是搬运工先搞清楚一个最基本的逻辑。你用ADO写程序访问数据库本质上是三件事建立连接、发送SQL命令、处理返回的结果。ADO的对象模型Connection、Command、Recordset解决的是“怎么把命令送过去”和“结果怎么接回来”而SQL语句解决的是“到底要数据库干什么”。一个不懂SQL的人去学ADO就好比你学会了怎么开车但完全看不懂导航说的“前方路口右转”——车开得再顺不知道该往哪走也白搭。我之前见过一个同事写的代码为了查出某个状态下的记录数先把整张表Load到Recordset里再用循环一条一条数。数据量小的时候没感觉表里塞了几十万条之后那界面的响应速度直接让人崩溃。后来改成一条SELECT COUNT(*) FROM 表 WHERE 状态有效瞬间出结果。这个对比基本说明了SQL水平的差距对程序性能的影响有多大。所以我的建议是先集中火力把SQL语句本身搞明白再去看ADO怎么用。这不是说ADO不重要而是说SQL是前置条件。1.2 学习SQL的正确路线从增删改查开始SQL的语法体系看起来很庞大但如果按实用频率去排序绝大部分业务代码里跑的都跳不出这几大门类查询SELECT、插入INSERT、更新UPDATE、删除DELETE以及配套的条件控制WHERE、排序ORDER BY、分组聚合GROUP BY / HAVING、多表关联JOIN和子查询。把这些东西掌握了你就已经能应付绝大多数开发场景了。我给自己定的练习路线很笨找一套常见业务场景比如学生选课、订单管理、商品库存把增删改查每一种操作都写一遍然后逐步往里面加条件、加排序、加统计、加多表关联。每加一个知识点对照执行结果去验证自己理解得对不对。这个阶段不碰任何代码就在数据库的查询工具里纯写SQL把语法本身的肌肉记忆先练出来。用查询工具练习有一个好处你能直接看到执行计划和返回结果写错了立刻就知道哪里有问题。而且因为不需要考虑程序代码的衔接可以把全部注意力放在SQL本身这对建立扎实的基础非常关键。2. SQL核心细节与实操要点2.1 查询与条件筛选WHERE的边界感要清晰SELECT是SQL里出场率最高的语句但很多人只停留在“SELECT 列 FROM 表”这个层面。实际业务里几乎每条查询都离不开WHERE条件而条件写得好不好直接决定了结果集是不是你要的以及查询跑得快不快。举一个我最常拿来举例的场景。假设有一张订单表你要查“最近30天内下单金额超过1000元的有效订单”。如果不假思索直接写SELECT * FROM 订单表 WHERE 下单时间 DATEADD(DAY, -30, GETDATE()) AND 金额 1000 AND 状态 有效这个写法本身没错但我见过不少人会写成WHERE 金额 1000 AND 状态 有效把时间条件漏了或者把时间条件写成下单时间 BETWEEN 2024-01-01 AND 2024-01-30这样的硬编码不做动态计算。前者查出来的数据范围不对后者到下个月代码就得改——这些都是WHERE条件“边界感”不清晰的表现。练习WHERE时我建议你刻意往这几个方向多加刁难自己的条件多条件组合AND和OR混用时必须加括号不然运算优先级会让你怀疑人生。范围判断BETWEEN是包含边界的如果你需要“大于等于起始值且小于结束值”那更适合用和组合。空值处理用IS NULL而不是 NULL这是一个新手最容易栽的坑。NULL和任何值做比较结果都是NULL也就是不成立所以WHERE 备注 NULL永远查不出数据。还有一个容易被忽略的点SELECT后面到底要不要写*。练习的时候随便写没事但到了实际项目里我强烈建议你把需要的列名一个个列出来。这不是洁癖而是实实在在的性能考量——你不需要的列也查出来会白白增加网络传输和内存开销。更重要的是程序代码里依赖列名时写明确列名能让接口更稳定表结构一变你马上就能感知到。2.2 排序与分页让结果有序可读ORDER BY看起来简单但也有些小细节值得注意。首先是排序方向ASC升序和DESC降序要分清默认是升序很多人忘了写ASC/DESC就拿到反着的顺序。其次是多列排序的优先级问题SELECT 姓名, 班级, 总分 FROM 学生成绩表 ORDER BY 班级, 总分 DESC这条语句的意思是先按班级升序排同一个班级内再按总分降序排。这个执行顺序符合直觉但当你写的列多了之后一定要自己心里有数哪一列是主导排序的。我之前就犯过把关键列写在后面的错误导致分组效果完全没出来看起来数据一团糟。如果涉及分页查询不同数据库写法不一样。SQL Server用的是OFFSET FETCHMySQL用的是LIMIT。比如SQL Server里查第11到20条数据SELECT 编号, 名称 FROM 商品表 ORDER BY 编号 OFFSET 10 ROWS FETCH NEXT 10 ROWS ONLY这里的OFFSET 10意味着跳过前面10条FETCH NEXT 10 ROWS ONLY取接下来10条。需要注意OFFSET FETCH必须搭配ORDER BY使用这是语法要求不排序就分页是不行的。当时我在练习时分页最容易犯的错是OFFSET算错。第二页的起始偏移应该是页码-1乘以每页条数不要拿着页码直接当偏移量用。这个错我犯过不止一次建议你拿小数据表亲手算一遍把偏移量的公式刻在脑子里。2.3 聚合统计与分组从明细数据到汇总信息业务报表里最常出现的就是“统计每个部门的平均工资”“按月份统计销售额”“找出订单数量前十的客户”这类需求全部离不开GROUP BY和聚合函数。常见的聚合函数有COUNT计数、SUM求和、AVG平均、MAX、MIN最大最小用法都很直观。但这里有一个核心规则你必须烂熟于心SELECT后面出现的非聚合列必须出现在GROUP BY里面。什么意思看这条SELECT 部门, AVG(工资) AS 平均工资 FROM 员工表 GROUP BY 部门“部门”是非聚合列所以它必须出现在GROUP BY中。如果你想在结果里同时显示员工姓名和部门平均工资抱歉这办不到——因为每个部门的平均工资只有一条汇总值而你有多名员工他们对应不上。这个规则违反之后数据库会直接报错但如果你用的一些老版本数据库或者某些特殊的查询模式可能不报错却返回莫名其妙的结果那更让人头疼。GROUP BY的难点是条件去哪写的判断。WHERE和HAVING都有筛选功能区别在于WHERE在分组前筛原始行HAVING在分组后筛组。如果你想查“2024年平均工资超过5000的部门”必须先先用WHERE把2024年的数据筛出来再分组求平均值最后用HAVING过滤掉平均工资不足5000的部门SELECT 部门, AVG(工资) AS 平均工资 FROM 员工表 WHERE 入职年份 2024 GROUP BY 部门 HAVING AVG(工资) 5000这个执行顺序我一开始老搞混后来用一句话记住WHERE管的是“哪些行能进来参与分组”HAVING管的是“哪些组能出现在结果里”。2.4 多表连接与子查询让分散的数据产生关联现实中的业务数据几乎不会放在一张表里订单和客户分开、文章和作者分开、商品和分类分开这是为了减少数据冗余也就是常说的范式化设计。所以要把这些分散的数据重新拼在一起看就需要用到JOIN。我最常用的是INNER JOIN和LEFT JOIN它们的区别用一句话说清INNER JOIN只保留两边能匹配上的数据LEFT JOIN保留左表全部数据右表能匹配上的就填值匹配不上显示NULL。举个例子订单表里有客户编号客户表里有客户名称。你想查所有订单和对应的客户名SELECT 订单表.订单编号, 客户表.客户名称 FROM 订单表 INNER JOIN 客户表 ON 订单表.客户编号 客户表.客户编号如果有一笔订单对应的客户信息被误删了INNER JOIN就会把这个订单漏掉而LEFT JOIN能让订单依然显示出来只是客户名称是NULL。这个差异在统计场景里影响很大比如“统计每笔订单及对应客户”你肯定不希望因为客户资料异常而让订单凭空消失所以左连接在报表场景里用得更多。练习多表连接时建议你从两表连接开始熟练之后再加第三张表。三张表连接容易出的问题是JOIN顺序混乱或者ON条件写错列导致笛卡尔积爆炸——结果集的条数变成各表条数的乘积数据量翻着倍地涨查询慢到怀疑人生。子查询就是嵌套在另一个查询里的查询它可以用在WHERE、FROM、SELECT等位置。我常用的场景是“先算出一个范围再作为主查询的筛选条件”。比如“查出比平均工资高的员工”SELECT 姓名, 工资 FROM 员工表 WHERE 工资 (SELECT AVG(工资) FROM 员工表)这种写法先查出一个标量值再拿去和每一行比较逻辑很清楚。子查询的一个坑是如果子查询返回了多行数据你只能搭配IN、EXISTS这类操作符不能直接用来和单值比较。我刚练的时候总在这里翻车报错信息提示“子查询返回了超过1个值”才意识到自己忘了这个限制。2.5 数据修改INSERT、UPDATE、DELETE的注意事项增删改这三类语句在面试和日常开发里都要写但它们有一个共同原则操作范围一定要控制好。少了WHERE的UPDATE和DELETE会把整张表的数据全改掉或全删掉——这在生产环境里属于灾难性事故。INSERT的常见写法有两种一种是带列名的插入INSERT INTO 员工表 (姓名, 部门, 工资) VALUES (张三, 技术部, 8000)另一种是从另一张表查出来的结果直接插入适合做数据迁移或备份INSERT INTO 员工备份表 (姓名, 部门, 工资) SELECT 姓名, 部门, 工资 FROM 员工表 WHERE 状态 离职无论哪种列名和值必须严格一一对应。少一个列、多一个值都会报错我刚学的时候经常因为数据类型不匹配折腾半天——往数值列塞字符串往日期列塞文本数据库那边直接甩一个转换失败的错误回来。UPDATE和DELETE的危险之处在于它们的“无差别攻击”比如DELETE FROM 员工表这条语句会清空整张表。怎么样才能只删掉指定的人加上WHEREDELETE FROM 员工表 WHERE 员工编号 42即便是更新一个字段我也建议你在生产环境里先看一眼WHERE条件覆盖的范围。写UPDATE之前先跑一条相同条件的SELECT确认你要更新的行数符合预期再做更新。这个习惯我用了几条血泪教训才养成现在已经成为我写数据变更逻辑的默认动作。3. 一个案例串起SQL核心语法从需求到落地3.1 设计一张成绩表把语法都串起来光学不练假把式。我给自己设计过一个学生成绩管理的练习场景整个练完一遍之后对SQL的整体把握一下子就立体了。这里也拆给你看看。先建三张表学生表学号、姓名、班级、课程表课程编号、课程名称、学分、成绩表学号、课程编号、成绩。成绩表通过学号和课程编号与学生表、课程表建立关联这就是典型的三表结构。练习的第一步是把基本数据插进去。我准备了五个学生、三门课程、若干条成绩记录然后开始从易到难地写各种查询。这个阶段不用管什么优化、索引之类的概念就是纯语法练习。3.2 从单表查询到多表统计逐条写出核心SQL下面是当时我练的一组有代表性的查询也是我从“会写SQL”到“能顺手写SQL”的分水岭。第一个是查出每个学生的选课数量SELECT 学号, COUNT(*) AS 选课数量 FROM 成绩表 GROUP BY 学号第二个是查出每门课程的平均成绩并按平均成绩降序排列SELECT 课程编号, AVG(成绩) AS 平均成绩 FROM 成绩表 GROUP BY 课程编号 ORDER BY 平均成绩 DESC第三个是带上了三表连接查出学生的姓名、课程名称和成绩SELECT 学生表.姓名, 课程表.课程名称, 成绩表.成绩 FROM 成绩表 INNER JOIN 学生表 ON 成绩表.学号 学生表.学号 INNER JOIN 课程表 ON 成绩表.课程编号 课程表.课程编号这个查询把三张表的关联做出来了逻辑是成绩表作为中间桥梁一边连学生表拿姓名一边连课程表拿课程名称。练到这里多表关联的基本套路就形成了。第四个是统计每个班级的平均分并且只保留平均分大于80的班级SELECT 学生表.班级, AVG(成绩表.成绩) AS 班级平均分 FROM 成绩表 INNER JOIN 学生表 ON 成绩表.学号 学生表.学号 GROUP BY 学生表.班级 HAVING AVG(成绩表.成绩) 80这个练习把连接、分组、聚合、过滤全部串在了一起是我觉得最具综合性的一条。当时我专门把这条语句的执行顺序写在笔记本上先连接两张表形成临时结果集再按班级分组接着对每组求平均分然后用HAVING过滤掉平均分不足80的组最后把需要的列展示出来。3.3 理解SQL的执行顺序这是调优的第一课就在练这些语句的过程中我慢慢发现了一个特别重要的事SQL里语句的书写顺序和它的实际执行顺序不是一回事。从书写上你是先写SELECT再写FROM、WHERE、GROUP BY、HAVING、ORDER BY但数据库执行的时候顺序是这样的FROM确定要读取哪张表WHERE过滤掉不满足条件的行GROUP BY按指定列进行分组HAVING过滤掉不满足条件的分组SELECT计算要返回的列ORDER BY对最终结果排序这个执行顺序解释了为什么WHERE里不能用SELECT里定义的别名——因为SELECT还没执行别名根本不存在。比如SELECT 工资 * 1.1 AS 新工资 FROM 员工表 WHERE 新工资 5000是错的数据库压根不认识“新工资”这个别名得写成WHERE 工资 * 1.1 5000才行。理解这个顺序对排查问题帮助极大。有时候你发现一条语句返回的结果和预期不符按执行顺序一步步倒推基本就能定位是过滤时机问题WHERE和HAVING用错了还是执行顺序认知有偏差。4. 常见问题与排查技巧实录4.1 入门阶段最容易犯的五个错误我把周围朋友和自己在练习中反复出现的错误整理了一个速查清单每一条都有真实翻车背景建议你写SQL时对照着自查用判断NULL在WHERE里写列名 NULL结果永远查不出数据必须用IS NULL。字符串少了引号在SQL里字符串必须用单引号包起来而且如果字符串本身包含单引号需要用两个单引号转义比如WHERE 姓名 OBrien。WHERE与HAVING不分忘记WHERE筛行、HAVING筛组这个原则往往查出来的汇总数据莫名其妙地多了或少了。聚合列混用不使用GROUP BY把非聚合列和聚合函数一起SELECT又不加GROUP BY报错或者结果不明确。OFF SET分页算错第二页的起始偏移应该是(页面索引-1)×每页条数很多人直接拿页号当偏移查出来的数据永远是前几页。这些大多属于“会者不难”的问题但架不住它们出现的频率实在太高。我在练习阶段给自己定了个规矩每条SQL写完习惯性检查一遍这几个位置——NULL判断、引号闭合、聚合列是否分组、WHERE和HAVING的位置能省下大量的排查时间。4.2 SELECT之外ADO调用SQL时的特有坑既然标题里带了ADO编程这里我先把SQL层面和ADO直接相关的几个问题说透。你在数据库工具里把SQL写对了不代表往ADO代码里一搬就万事大吉有两个坑是ADO环境下特别容易踩的。第一个是参数化查询的问题。之前我在某公司做一个小工具的时候图省事直接拼SQL字符串比如string sql SELECT * FROM 用户表 WHERE 姓名 用户名 ;这种做法最大的风险是注入漏洞——用户名里如果包含 OR 11 --这样的内容整个查询的逻辑就被改写了。更稳妥的做法是使用参数化查询把用户输入当作参数传进去而不是拼进SQL字符串里。ADO里有Command对象配合Parameters集合来实现这一点虽然代码量会多一些但安全和稳定性的提升是绝对值得的。在学习阶段就把参数化养成习惯比以后线上出了事故再回头补课要划算得多。第二个是SQL语句中字符串内的单引号问题。ADO里用SQL字符串时文本内的单引号需要转义为两个单引号比如要查OBrien这个人在SQL里就必须写成OBrien。代码里如果你是用字符串拼接的方式处理这个转义很容易被忽略导致运行时抛SQL语法错误。这个问题非常隐蔽因为数据库管理工具里直接执行SQL时你可能刚好写对了而代码里经过一层拼接就可能出问题。4.3 排查思路从执行计划的视角找问题遇到SQL执行慢的情况不要急着去改代码先在数据库里跑一下这条语句的“执行计划”。执行计划就是数据库告诉你它打算怎么执行你这条SQL先读哪张表、怎么关联、用没用索引、有没有全表扫描。以前我发现一条分页查询随着数据量增大越来越慢打开执行计划一看排序操作占了大头而且没有走索引。原因是我排序的列没建索引导致数据库把整张表的数据都读出来后做了一次昂贵的排序操作。后来给排序列加上索引查询速度提升了好几个数量级。这个问题的教训是SQL慢不一定是你写得不对也可能只是索引缺失或者表设计不合理。但反过来说如果你SQL写法本身有问题比如关联条件不明确导致的笛卡尔积再好的索引也救不了你。所以排查顺序建议先看SQL语义对不对再看执行计划最后才动代码或加索引。写在最后的学习建议这篇总结写到这里SQL语句的核心内容基本都覆盖到了。我个人在实践中的一个体会是SQL这门技能看十遍教程不如亲手写一遍。建议你找一套自己熟悉的数据场景按我上面的练习路线从单表查询一直练到多表统计每一条语句都实际跑一遍看看结果和你想的是否一致。不一致的地方就是你理解还有偏差的地方那才是真正涨知识的地方。还有一个小技巧分享给大家平时在程序代码里写SQL之前先在数据库查询工具里把SQL单独跑通确认结果正确后再搬到代码里。这样能帮你把SQL本身的错误和程序代码的错误隔离开排查问题的时候会清爽很多。这个习惯我一直用到现在大大减少了两边同时出问题时的混乱局面。SQL这块地基打牢之后下一步就可以放心去啃ADO编程了。等我把ADO那部分笔记也整理完再接着写这个系列的第二篇。