简介涵盖SQL数据库经典笔试题与规范标准答案的PDF文档面向准备技术面试与笔试的求职者也适合需要快速回顾SQL基础的开发人员。围绕互联网岗位常见的数据库考查方向整理出多道高频题目覆盖分组聚合、排序过滤、多表连接、子查询、极值统计等核心知识点每题均给出可直接运行的SQL语句其中收入汇总、最高分查找等题目还附有多种等价写法便于对比理解不同实现思路。资源共1个文件为PDF格式压缩包约1.38MB内容轻量、便于打印或离线学习。已有190人学习下载。系统过一遍这些题目后可熟悉面试中常见的SQL出题方式掌握GROUP BY、JOIN、TOP/ORDER BY、嵌套查询等关键语法的实际用法也能对照规范答案及时自查覆盖从基础查询到多表复杂查询的常见场景适合在笔试或面试前集中冲刺复习。1. 修改笔试题为什么总是整张卷子里丢分最狠的一页前阵子帮一位刚转行的朋友看 SQL 笔试卷子他 SELECT 题几乎全对窗口函数也写出了花结果栽在一道只有三行的 UPDATE 题上。后来我翻了几份《SQL数据库经典编辑面试题(修改笔试题)(有规范标准答案)》这类题库发现这不是个例凡是带修改二字的题正确率都比查询题低一大截。原因很直白——写 SELECT 错了最多查不出数写 UPDATE、DELETE 或者 ALTER 错了轻则把测试库改花重则连累一套业务。判卷人对这类题天生带着你敢改我敢扣的警惕答案规范与否一眼就能看出来。这份材料表面上是题集本质上是把改数据这件事里最容易出错的动作全部抽象成了考题修改前怎么确认影响范围、修改时怎么写 WHERE、修改后发现错了能不能后悔。适合三类人读准备笔面试的开发岗和初级 DBA、需要拿现成题库出题的技术负责人以及刚拿到生产库写权限、准备动第一行数据的新人。接下来的内容不按题目顺序讲按先会写再写稳最后能讲清楚的顺序拆。2. UPDATE 题的答题骨架先让阅卷人相信你不会用错 WHERE2.1 最小可用模板三段式 SQL 让影响范围透明化修改笔试题里出现频率最高的就是单表 UPDATE。很多人一上来就写UPDATE ... SET ... WHERE ...语法没问题但阅卷人没法判断你心里有没有数。标准答案的写法通常是三段式先查、再改、再核。-- 第一步用 SELECT 确认将要被修改的数据长什么样 SELECT order_id, customer_id, status, pay_time FROM orders WHERE customer_id 2024001 AND status PENDING; -- 第二步确认无误后执行 UPDATE条件与第一步完全一致 UPDATE orders SET status PAID, pay_time 2024-06-01 10:30:00 WHERE customer_id 2024001 AND status PENDING; -- 第三步核对是否还有漏网的 PENDING 单 SELECT COUNT(*) AS remaining_pending FROM orders WHERE customer_id 2024001 AND status PENDING;这段代码的逻辑核心是UPDATE 的 WHERE 条件必须和第一步 SELECT 的 WHERE 条件一字不差。如果第一步查出 3 条第三步查出来 0 条说明 3 条全部改掉了这个闭环本身就是答案的验证过程。参数上注意两点一是pay_time这种显式赋值在 SQL Server 里习惯写成GETDATE()MySQL 则是NOW()题型没指定数据库时写可读性最好的标准字面量不会错二是 SET 里多个字段用逗号分隔不要用AND连接字段赋值这是一个低级但高频的错误。这套三段式在卷面上还有个隐性优势它把我担心误操作的态度写进了代码里。判卷人看到一个事务都没开的答案心里已经默认你是新手看到先查后改反而会愿意继续往下看。2.2 标准答案的节奏为什么永远先 SELECT 再 UPDATE 再核对这套题库的答案几乎每道修改题都是同一个节奏不是巧合。先 SELECT 的本质是锁定影响面UPDATE 是执行变更最后那次 SELECT 是验证结果。三段缺一段答案的完整度就打折扣。常见误用是有人把验证简化成一句SELECT ROWCOUNT然后拿受影响行数当结论。行数对不等于业务对假设 WHERE 条件写窄了本该改 100 行只改了 50 行ROWCOUNT返回 50正确执行但业务目标是 100。反之条件写宽了改了 120 行ROWCOUNT也只会告诉你成功了 120 行不会告诉你里面混了 20 行不该动的数据。所以影响行数是验证的辅助参数不是替代条件去跑一遍 SELECT 的理由。标准答案坚持用改前查 count、改后查 count对拍就是为了把这层风险降到最小。还有一层原因是业务语义验证。只盯着 count 对无法确认改完的状态值是否符合预期把改完的数据 SELECT 出来看几行才能发现 SET 赋值是不是把字段写反了。实战中我改完重要字段后一定会带出主键和变更字段跑一次对照这题考的就是这个习惯。2.3 多表修改的两种写法MySQL 和 SQL Server 的改法不一样修改笔试题升级版是关联修改典型场景是根据客户等级回填订单表里的销售员名称。这题在 MySQL 和 SQL Server 里的写法完全不同用错一套语法在另一套环境直接报错。-- MySQL 写法JOIN 直接跟在 UPDATE 后面 UPDATE orders o JOIN customers c ON o.customer_id c.id SET o.sales_name c.sales_name WHERE c.level VIP; -- SQL Server 写法UPDATE 后写别名JOIN 放到 FROM 子句 UPDATE o SET o.sales_name c.sales_name FROM orders AS o JOIN customers AS c ON o.customer_id c.id WHERE c.level VIP;逻辑上两句等价都是把 customers 表里 level 为 VIP 的客户对应销售员名称回写到 orders 表。差别在语法组织MySQL 的关联表在 UPDATE 关键字之后直接出现SQL Server 则要求先写要更新的目标表别名关联关系全部下沉到 FROM 里。这个差异在笔试里是很好的区分点能写两种的人才说明不是只会 Navicat 点点点。参数和性能上要注意JOIN 的关联字段必须建索引customers.id和orders.customer_id如果有一侧没索引小表数据量看不出问题生产环境几百万行订单时就会把更新拖成慢查询。另外如果用了 LEFT JOIN 而不是 INNER JOIN匹配不到的右侧字段会以 NULL 覆盖目标列这是关联更新里最阴的坑——sales_name被 NULL 冲掉后行数没错数据没了后面的业务直接黑匣子。所以关联更新一律先用 SELECT 验证 JOIN 命中范围再转成 UPDATE这也是后续 java、mybatis 岗位笔试题里常拿来延伸的场景。3. ALTER 与 DELETE改表结构和删数据也有标准答案3.1 ALTER 的三类高频题加列、加约束、调类型修改笔试题不只是改数据行改表结构同样高频。这类题考的是对数据库元数据操作的理解答案里最容易出现的问题是只会写 ADD COLUMN一旦要求改约束或改类型就露馅。常用的 ALTER 操作可以用一张表覆盖操作SQL Server 语法MySQL 语法注意事项增加列ALTER TABLE employees ADD department_id INT NULL同左先允许 NULL避免老数据写入失败增加外键ALTER TABLE employees ADD CONSTRAINT fk_dept FOREIGN KEY (department_id) REFERENCES departments(id)同左外键列必须与引用列类型一致修改列类型ALTER TABLE employees ALTER COLUMN department_id BIGINTALTER TABLE employees MODIFY COLUMN department_id BIGINT类型转换失败会直接报错加非空约束ALTER TABLE employees ALTER COLUMN department_id INT NOT NULLALTER TABLE employees MODIFY COLUMN department_id INT NOT NULL表里有 NULL 值时执行必失败笔试题里最常埋的坑是最后一行改 NOT NULL。很多人直接拿ALTER COLUMN去执行然后报错说有 NULL 值无法完成。标准答案的流程应该是先UPDATE employees SET department_id 0 WHERE department_id IS NULL把空值补齐再执行 NOT NULL 约束修改。这道题考的不是语法而是思考顺序。ALTER 的实际执行代价也值得在答案里提一句ADD COLUMN 在 MySQL 8.0 之前会锁表重建8.0 后支持 INSTANT ADD COLUMNSQL Server 加列时如果指定 NOT NULL 且带默认值元数据操作可以瞬间完成但没指定默认值就会扫全表回填。能把这些边界条件写清楚这道题就从会语法升到懂数据库了。3.2 DELETE 题的边界TRUNCATE 与 DROP 的取舍删数据在修改笔试题里通常以对比题出现让你区分 DELETE、TRUNCATE、DROP 三者差异。这题丢分往往不是因为不知道语法而是说不清哪个能回滚、哪个保留结构、哪个释放空间。维度DELETETRUNCATEDROP作用对象数据行可加 WHERE整张表的全部数据整张表连同结构和数据是否可回滚事务内可回滚SQL Server / MySQL 均可回滚但 MySQL 下隐式提交前才有效大部分环境不可回滚无备份就是永别保留表结构保留保留不保留性能特点逐行删慢会产生大量日志按页释放快日志极少瞬间释放几乎无日志自增列不重置自增列重新从 1 开始表没了谈不上自增这里最反直觉的一条是 TRUNCATE 能不能回滚。不少资料写TRUNCATE 不能回滚严格说在 SQL Server 里只要在显式事务中执行 TRUNCATEROLLBACK 是有效的MySQL 在开启事务并尚未隐式提交时同样可以回滚。笔试题如果把不能回滚当成铁律遇到较真的阅卷人反而失分。稳妥的答案是TRUNCATE 的操作日志远少于 DELETE是否可回滚取决于是否位于显式事务中。DELETE 题的标准答案还会带一个 WHERE 判断。写DELETE FROM orders不加 WHERE语法满分但是事故写DELETE FROM orders WHERE order_date 2024-01-01至少表明你知道删数据必须带范围。题目没说事务时主动补一句执行前开事务删完核对影响行数再 COMMIT更是加分项。3.3 标准答案的兜底习惯动手前先留后悔药很多标准答案在 DELETE 或大范围 UPDATE 题后面藏了一步备份。笔试不强制写但写了就比参考答案高一档。-- 修改前把目标数据复制到临时备份表 IF OBJECT_ID(tempdb..#orders_bak) IS NOT NULL DROP TABLE #orders_bak; SELECT * INTO #orders_bak FROM orders WHERE order_date 2024-01-01; -- 正式删除事务包裹后悔药在握 BEGIN TRAN; DELETE FROM orders WHERE order_date 2024-01-01; -- 核对备份表行数必须等于受影响行数 -- 如果 SELECT COUNT(*) FROM #orders_bak 和 ROWCOUNT 对不上立刻 ROLLBACK COMMIT;这段代码的工艺在于备份表 SELECT INTO 在事务外先执行即使后面删除出问题备份数据也不受 ROLLBACK 影响这是备份的意义。事务内的 DELETE 负责可回滚事务外的备份表负责最终兜底两层后悔药叠加生产事故就能降级成一句从备份表捞回来就行。临时表#orders_bak在当前会话结束后自动消失适合笔试答题生产环境标准做法是建正式备份表或者用CREATE TABLE orders_bak_20240601 AS SELECT ...保留现场。题目如果问如何保证误删后数据能恢复把这两层备份逻辑讲出来比只说开事务更让面试官满意。4. 事务、锁与变更窗口修改题从及格到高分的分水岭4.1 让修改可回滚BEGIN TRAN 不是装饰是答题的底线修改笔试题答到事务层是区分会写 SQL和敢动生产库的分界线。标准答案里只要有 UPDATE/ DELETE大概率藏着事务模板SET XACT_ABORT ON; -- 任一语句出错时自动回滚整个事务 BEGIN TRANSACTION; UPDATE accounts SET balance balance - 200 WHERE account_no 622200001 AND balance 200; -- 条件自带余额校验避免出现负余额 UPDATE accounts SET balance balance 200 WHERE account_no 622200002; -- 核对上一条语句影响行数都是 1 才提交 IF ROWCOUNT 1 COMMIT; ELSE ROLLBACK;这里的逻辑核心是两条 UPDATE 要么都成功、要么都失败。如果只改第一条不改第二条钱就凭空消失了。XACT_ABORT ON的作用是把运行时错误从只回滚出错语句升级为回滚整个事务加了这一行事务的原子性才真正立住。参数上有几个笔试常考的点ROWCOUNT返回的是上一条语句影响的行数所以 IF 判断必须紧跟在第二条 UPDATE 之后中间不能夹 SELECT否则取到的是 SELECT 的行数balance 200这个条件相当于应用层加的乐观约束防止并发情况下余额扣成负数。如果题面问如何防止扣款超余额标准答案一是 WHERE 里带余额条件二是更新后立刻检查两者兼用最稳。4.2 并发修改更新丢失与死锁的答题话术修改题的高阶考点躲不开并发。面试官常见问法是两个事务同时修改同一行数据会发生什么如果只是机械回答会锁住深度不够。实际现象分两种都需要在答案里拆开讲。更新丢失Lost Update的经典路径是事务 A SELECT 出余额 1000事务 B 也 SELECT 出 1000A 改成 1200 提交B 基于旧的 1000 改成 800 提交最后结果是 800A 的修改被覆盖。这在默认的读已提交隔离级别下完全可能发生因为 SELECT 不加锁。解决方式是在修改前给目标行加更新锁BEGIN TRANSACTION; SELECT balance FROM accounts WITH (UPDLOCK) -- SQL Server 行级更新锁 WHERE account_no 622200001; -- 拿到最新余额后在应用层计算再执行 UPDATE UPDATE accounts SET balance 1500 WHERE account_no 622200001; COMMIT;MySQL 里对应的是SELECT ... FOR UPDATE同样锁定命中行直到事务结束。这个答案的核心逻辑是先锁后改避免基于过期数据覆盖写。至于死锁答题话术是两个事务各自持有一行数据的锁又同时去要对方手里的锁互相等待。解决办法不外乎三条所有事务按相同顺序访问资源、事务尽量短、索引要合理避免锁范围扩大。能说清更新丢失是看不见的逻辑错死锁是数据库主动报错让你发现这层理解基本就过关了。4.3 大表修改拆批次一条 UPDATE 打全场是噩梦笔试里有一类题专门钓大意的给一张 500 万行的表要求把某个状态字段批量更新题干还轻描淡写一句更新期间业务不可中断。直接写一条 UPDATE 的人答案看似正确实际上在 SQL Server 里会触发锁升级把行锁升级成表锁读业务全部堵死MySQL 里则可能把 undo 日志撑爆主从延迟飙到分钟级。标准答案的底层逻辑是拆批。DECLARE batch_size INT 5000; DECLARE rows INT 1; WHILE rows 0 BEGIN -- 每次只更新 5000 行TOP 限制单批数量WHERE 限定未更新的目标 UPDATE TOP (batch_size) tickets SET status_id 90 WHERE status_id 10 AND due_date GETDATE(); SET rows ROWCOUNT; -- 本批影响行数为 0 时循环自然结束 WAITFOR DELAY 00:00:01; -- 每批间隔 1 秒让出锁资源 END这里的参数设计直接关系到生产是否翻车batch_size一般设在 2000 到 10000 之间太小了循环次数多太大退化回长事务WAITFOR DELAY 00:00:01是给其他事务喘息窗口让读请求有机会插队。MySQL 没有 TOP 语法常见做法是UPDATE ... WHERE id BETWEEN ? AND ?配合主键分片或者LIMIT 5000循环同样能实现。这道题的标准答案如果只写了循环没写批次大小和间隔我会当作不完整。因为面试官真正想听的是你清楚长事务对锁、日志、主从延迟的三重影响而不是单纯堆代码。5. 修改题的五种翻车现场判卷标准不会写的隐性扣分点5.1 子查询当过滤条件WHERE 范围比想象中宽现象答案里写UPDATE orders SET status PAID WHERE customer_id IN (SELECT id FROM customers WHERE level VIP)阅卷人追问VIP 客户有多少答不上来甚至没跑过子查询。原因把子查询当成了装样子没有先验证它返回的结果集。子查询可能命中 0 行也可能命中全表IN (SELECT ...)遇到空结果集时 UPDATE 一行都不改答案语法满分但功能失效。解决任何带子查询的 UPDATE第一步永远单独执行子查询看命中范围和预期是否一致再把它嵌进 WHERE 条件。这也是前面三段式方法论在子查询场景的延伸。5.2 排序删除的方言差异把 MySQL 的 LIMIT 带进 SQL Server现象答案写DELETE FROM logs ORDER BY create_time LIMIT 1000在 MySQL 环境能跑拿到 SQL Server 面卷上直接语法错误整题零分。原因MySQL 支持 DELETE 配合 ORDER BY 和 LIMITSQL Server 的 DELETE 不支持 ORDER BY除非写 CTE两种方言混用是常见的翻车现场。解决SQL Server 下用 CTE 加 TOP 实现WITH cte AS ( SELECT TOP (1000) id FROM logs ORDER BY create_time ) DELETE FROM logs WHERE id IN (SELECT id FROM cte);答题时如果没指定数据库最好开头声明以下写法基于 XXX 数据库这句话能救回一半分。5.3 影响行数对不上隐式类型转换让 UPDATE 多改几行现象执行完 UPDATE 后 SELECT 验证发现多改了两条不该改的数据业务上表现为状态被莫名重置。原因WHERE 条件里字段是 VARCHAR却用数字去匹配数据库做了隐式类型转换。例如WHERE order_no 1001order_no 实际存储为01001转换规则可能让多条数据匹配上同一个条件。解决验证阶段用SELECT * FROM orders WHERE CAST(order_no AS CHAR) 1001先探明真实匹配结果写 UPDATE 的条件时必须显式转换不让数据库猜。这条踩坑经验适用于任何类型敏感的字段身份证号、订单号这类前置补零的字段尤其容易中招。5.4 触发器连坐改一张表另一张表数据悄悄变了现象执行 UPDATE 后主表数据正确过一会儿下游报表发现汇总数据翻倍排查半天找不到是谁改的。原因表上挂着 AFTER UPDATE 触发器你的 UPDATE 触发了它的连带修改可能是同步其他表也可能更新了冗余字段而答题人完全没有意识到触发器的存在。解决修改前先查当前库的触发器清单-- SQL Server 查看某表上的触发器 SELECT name, is_instead_of_trigger FROM sys.triggers WHERE parent_id OBJECT_ID(orders);笔试答案里写改表前检查该表是否挂触发器评估连带影响这句话会让阅卷人高看一眼。生产环境如果确认触发器逻辑已有问题标准流程是先禁用再修改改完确认无误后重新启用不要硬扛。5.5 锁升级拖垮整库行锁无声变成表锁现象一条 UPDATE 在生产跑完业务方反馈说期间所有读写都卡了几十秒监控显示锁等待暴涨。原因语句更新的行数太多数据库引擎自动把行锁升级为表锁。笔试题不会让你看到监控但它会用大表更新如何不停业务来考同一件事。解决就是 4.3 说的拆批次但只拆批次还不够——批次内 UPDATE 的 WHERE 条件要能走索引否则每批都在全表扫拆了等于没拆。标准组合是索引条件定位 每批限行数 批次间停顿三者缺一不可。答题时补一句更新前先用执行计划确认 WHERE 走索引这一条能堵住大部分追问。6. 把规范标准答案的套路变成自己的肌肉记忆整套《SQL数据库经典编辑面试题(修改笔试题)》看下来你会发现所谓规范标准答案翻来覆去就是一套五步流程先确认影响面再开事务留后悔药然后执行修改接着核对影响行数与残留数据最后决定提交还是回滚。语法可以千变万化这五步的顺序一次都不能乱。我后来养成的习惯是把这五步做成一个固定模板凡是动生产数据的操作哪怕只改一行也照着走一遍肌肉记忆比临场思考可靠得多。考前刷这套题的正确姿势不是背答案而是拿答案对照自己的答题习惯。看到一道修改题先在草稿纸上写出先查、再改、后核三段骨架看到 DELETE 题条件反射地问自己备份了吗事务开了吗; 看到 ALTER 题第一反应必须是表里有没有 NULL加约束会不会炸。把这些细节练成条件反射笔试时根本不需要临场思考手会自己写。任何修改都意味着风险而风险补偿只有两样东西能把数据恢复的备份和能把错误回滚的事务。你在卷子上写下的每一句 WHERE都是给判卷人的一份安全承诺。希望这份踩坑总结能帮你在下一次笔试里稳稳接住所有修改题。本文还有配套的精品资源点击获取