数据库课后实验全攻略：从建库建表到事务权限的实操指南

简介：数据库课后实验（崔巍编著）资料包面向高校数据库课程初学者，用于配合教材完成课堂知识的实践巩固。压缩包共5个文件，全部为SQL脚本，整体大小仅5KB，内容轻量、可直接导入数据库运行。脚本分别对应建表、数据插入、更新删除、单表查询与多表关联查询等典型实验环节，能够帮助读者系统训练结构化查询语言的基础写法与常见子句搭配。资源延续教材中关于关系数据库设计范式、事务处理等知识点的讲解，通过具体语句展示如何将第一范式、第三范式以及原子性、一致性等理论落实到实验操作中。由于文件数目少、类型统一，读者可快速定位代码片段，对照课本习题查漏补缺；目前已有220人学习下载，尤其适合正在选修数据库课程、需要参考实验答案或练习样例的学生。

1. 数据库课后实验：从抄答案到自己出答案的关键一步

如果你正被数据库课后实验拖着走，大概率遇到过这种场景：教材翻完了，打开数据库软件却不知道第一条语句从哪写起；抱着网上找份答案抄一抄的想法，结果贴进自己库里全是语法报错。这套课后实验资源要解决的不是替你把代码准备好，而是告诉你实验该怎么做、每道题做到什么程度算过关、实验报告怎么排版才不丢分。适合三类人：正在修数据库课要交实验报告的学生、准备复试机试但想快速找回 SQL 手感的人、刚入职需要补数据库基本功的前端和测试。看完这篇，你能照着把建库、查询、事务、权限四类实验完整跑通。

2. 实验环境与报告模板：装库建库三步走，别急着敲代码

拿到实验题目后最忌讳的事，就是打开编辑器直接敲 CREATE TABLE。先花半小时把环境和验收标准定下来，后面每个实验至少省两小时。

2.1 选 SQL Server 还是 MySQL：先看教材再决定

数据库课后实验的教材多数基于 SQL Server 编写，里面的演示语句用的是 T-SQL 方言，比如 GETDATE()、TOP n、PRINT；如果课件里用的是 MySQL，就要把建表语句里的 AUTO_INCREMENT 和 ENGINE=InnoDB 单独记下来。判断依据很简单：打开实验指导书的章节标题，出现“T-SQL”“SQL Server Management Studio”“SSMS”字样，就沿用它；出现“Navicat”“workbench”就按 MySQL 走。

环境装好之后，第一步不是建库，而是验证能不能连上服务。Windows 下最稳的方式是先用 SQL Server Management Studio 登录一次，确认实例名和认证模式；连接字符串记成下面这种，后面所有命令行操作都用它：

# 本机默认实例，Windows 身份验证 sqlcmd -S localhost -E # 本机命名实例，SQL Server 身份验证 sqlcmd -S localhost\\SQLEXPRESS -U sa -P '你的密码'

参数说明：-S 指定服务器实例名，localhost 是本机默认实例，SQLEXPRESS 是安装时可选命名实例；-E 表示 Windows 身份验证；-U 和 -P 是 SQL Server 登录名和密码。第一次连接如果报“用户 sa 登录失败”，说明安装时选了 Windows 身份验证模式，需要用管理员身份打开 SSMS，在服务器属性里把身份验证模式改成“混合模式”。

验证连通后，执行一条最简单的语句确认当前库和版本：

SELECT @@VERSION AS 版本信息;

这条语句常用来做连通性测试，因为哪怕建库权限都没有，SELECT 系统变量也不受影响；能看到版本号就说明服务、端口、认证三层都通了，后面建库报错就不是连接问题，而是权限或语法问题。

2.2 读懂实验指导的目录结构：每个实验对应哪个知识点

这套课后实验的资源目录通常按教材章节排布，常见结构是这样的：

实验序号	实验内容	对应章节	验收标准
实验一	创建数据库与基本表	第 3 章 关系数据库	库、表、约束齐全，能查出表结构
实验二	数据更新（增删改）	第 4 章 SQL 数据操作	影响行数与预期一致
实验三	单表与多表查询	第 5 章 查询	能解释每条 SQL 的查询意图
实验四	视图与索引	第 6 章 视图与索引	查询走索引，视图可继续查询
实验五	事务与存储过程	第 7 章 事务	能演示回滚前后数据变化
实验六	用户与权限管理	第 8 章 数据库安全	授予与撤销权限生效

表格里的验收标准是我反复对比后补出来的，因为很多实验指导只写了“运行并观察结果”，没有写“做到什么程度算完成”。比如实验一，光建表成功还不够，还要能看到主外键约束在错误插入时拦截；实验三，能跑出结果只算一半，还要能说清楚为什么用 INNER JOIN 而不是 LEFT JOIN。

读目录时重点看两处：实验指导的“实验目的”段，通常会写明“掌握”“理解”“了解”三个层级；带“掌握”的知识点就是必考必交的内容，可以在报告里对应写出你的理解；“了解”层级的可以不写进报告，但答辩时老师可能追问。

2.3 实验报告的四段式结构：代码、截图、问题、体会

每次实验报告都遵循同样的四段结构，这样老师批起来不费劲，你的分数也稳定。

第一段写实验目的，直接抄指导书的原句，控制在三行以内；第二段写关键代码和结果截图，这是唯一值得花时间的地方，代码一定要带行号注释，截图一定要有“影响行数”或者结果集；第三段写踩坑记录，哪怕一个标点错误都写进去；第四段写小结，三句话：实现了什么、没用上什么、下次怎么做。

这套模板不是形式主义。数据库实验扣分最常见的原因是“有结果没过程”，老师从截图看不出你这几步是自己敲的还是复制的；带上注释的代码块、带上报错信息的排查记录，才是区分度所在。

3. 四类核心实验：建表、增删改、查询、视图索引一次打通

这四章是连续实验：建库建表、数据更新、数据查询、视图索引，一次课一个题目，但底层逻辑是串起来的。这里以“学生-课程-选课”三张表为例，把每类实验的标准答案和变体都写出来。

3.1 实验一：建库建表，主外键和约束一个都不能少

建库建表是后面所有实验的地基，教材里的写法通常是这样：

CREATE DATABASE StudentDB; GO USE StudentDB; GO CREATE TABLE Student ( Sno CHAR(9) PRIMARY KEY, Sname VARCHAR(20) NOT NULL, Ssex CHAR(2) DEFAULT '男', Sage SMALLINT CHECK (Sage BETWEEN 15 AND 30), Sdept VARCHAR(20) ); CREATE TABLE Course ( Cno CHAR(4) PRIMARY KEY, Cname VARCHAR(40) NOT NULL, Cpno CHAR(4), -- 先修课 Ccredit SMALLINT CHECK (Ccredit > 0) ); CREATE TABLE SC ( Sno CHAR(9), Cno CHAR(4), Grade DECIMAL(4,1), PRIMARY KEY (Sno, Cno), FOREIGN KEY (Sno) REFERENCES Student(Sno), FOREIGN KEY (Cno) REFERENCES Course(Cno) );

逻辑说明：Student 表用学号做主键，Sage 字段加 CHECK 约束限制年龄范围，Ssex 字段设默认值，保证非法数据进不来；Course 表的 Cpno 是自引用外键，指向自己的主键，表示先修课程关系；SC 表是典型的关联表，主键是 (Sno, Cno) 联合主键，两条外键保证选课记录必须指向真实存在的学生和课程。

参数说明：CHAR(9) 定长字符串，学号固定 9 位时不浪费空间；VARCHAR(20) 变长，姓名长度不一更省空间；DECIMAL(4,1) 表示共 4 位、小数 1 位，正好存 0.0 到 999.9 的成绩。这些类型选择本身就是考点，报告里写一句“学号定长、姓名变长”能体现你懂类型设计。

建完表后一定要执行下面这条语句自查，这也常是老师检查你是否自己动手的手段：

USE StudentDB; SELECT TABLE_NAME, COLUMN_NAME, DATA_TYPE, IS_NULLABLE FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME IN ('Student','Course','SC') ORDER BY TABLE_NAME, ORDINAL_POSITION;

这条查询从系统信息架构视图读取表结构，如果结果集完整显示了三个表的全部字段，说明建表成功；如果某个表缺失，多半是 CREATE TABLE 语句里有语法错误被跳过了。注意系统视图名必须大写，小写在某些 SQL Server 排序规则下能跑通，但在 MySQL 5.7 以下版本会因为大小写敏感报错。

3.2 实验二：数据更新，INSERT、UPDATE、DELETE 的边界条件要写清

数据更新实验看起来简单，但得分点全在“影响行数”和“是否误操作”上。先看标准插入：

INSERT INTO Student (Sno, Sname, Ssex, Sage, Sdept) VALUES ('20230001', '张三', '男', 20, '计算机系'); INSERT INTO Student (Sno, Sname, Ssex, Sage, Sdept) VALUES ('20230002', '李四', '女', 19, '数学系'); SELECT * FROM Student;

每条 VALUES 插入一行数据；字段列表的顺序可以和表结构不同，只要值对应上即可。注意如果把 Sage 插入成 40，会触发 CHECK 约束报错；如果把 Sname 省略，会触发 NOT NULL 约束报错。这两类报错是实验报告里最好的踩坑素材。

批量插入经常被忽略，但实验指导里常有“向选课表插入 20 条记录”的题，手写 20 条太累，可以用查询插入：

INSERT INTO SC (Sno, Cno, Grade) SELECT Sno, 'C001', 85 FROM Student WHERE Sdept = '计算机系';

这段语句从 Student 表查出计算机系所有学生，统一插入选课表，成绩 85 分；SELECT 子查询的结果集直接作为 INSERT 的数据源，适合批量造数。注意 SELECT 查出来的列数必须和 INSERT 指定的列数一致，这里固定一列 'C001' 和一列 85，能匹配两列，运行后消息框会显示“影响 N 行”，这个数字要写进报告。

更新语句的坑在于 WHERE 条件，漏写就是全表更新：

UPDATE SC SET Grade = Grade * 1.05 WHERE Cno = 'C001'; -- 危险写法，谨防演示翻车 -- UPDATE SC SET Grade = Grade * 1.05;

第一段真的想更新 C001 课程成绩，加 5%；第二段注释里是不带 WHERE 的危险写法，一旦执行,全表成绩都变。我一般会在实验指导的醒目位置把这个对照写在报告里，让老师知道你明白“不带 WHERE 就是全表操作”这个后果。

删除操作的边界条件也类似。DELETE 是 DML 操作，可回滚；TRUNCATE 是 DDL 操作，不可回滚，除非事务里。教科书常把二者对比作为简答题，实验时只需记住一句口诀：要回滚用 DELETE，要清空且不记录日志用 TRUNCATE。

3.3 实验三：单表查询、多表连接和子查询的写法对比

查询实验是整套课后实验里分值最大的部分，也是期末机试的重灾区。先看单表查询的基础套路：

SELECT Sno, Sname, Sage FROM Student WHERE Sdept = '计算机系' ORDER BY Sage DESC;

这条查询加了三个要点：WHERE 做行筛选，ORDER BY 做排序，DESC 表示降序。如果结果需要不重复，要写 SELECT DISTINCT；如果只想取前几条，SQL Server 用 SELECT TOP 3，MySQL 用 LIMIT 3，方言差异就在这里。

多表连接是三张表之间最常见的考点，教材的标准答案是内连接：

SELECT Student.Sno, Sname, Cname, Grade FROM Student INNER JOIN SC ON Student.Sno = SC.Sno INNER JOIN Course ON SC.Cno = Course.Cno WHERE Course.Cname = '数据库'

逻辑说明：先拿 Student 和 SC 按学号连接，得到每个学生选了什么课；再和 Course 按课程号连接，得到课程名；WHERE 最后过滤，只留数据库这门课。执行顺序是先 FROM 和 JOIN 生成虚拟表，再 WHERE 过滤，再 SELECT 投影，所以别名能用 WHERE 而聚合结果不行。

很多同学分不清 INNER JOIN 和 LEFT JOIN 的区别，实验里最好的验证方式是查“没选课的学生”：

SELECT Student.Sno, Sname FROM Student LEFT JOIN SC ON Student.Sno = SC.Sno WHERE SC.Sno IS NULL;

这段查询用 LEFT JOIN 保留左表所有学生，再用 SC.Sno IS NULL 过滤出没在选课表出现过的学生，也就是没选任何课的人。如果这里用了 INNER JOIN，没选课的人根本不会出现在连接结果里，IS NULL 条件永远不成立；这种语义差别就是机试里的送命题。

子查询的花样更多，最常见的是 IN 版本的不相关子查询和 EXISTS 版本的相关子查询：

-- 查询选修了课程号为 C001 的学生姓名（不相关子查询） SELECT Sname FROM Student WHERE Sno IN (SELECT Sno FROM SC WHERE Cno = 'C001'); -- 查询选修了课程号为 C001 的学生姓名（相关子查询） SELECT Sname FROM Student WHERE EXISTS ( SELECT 1 FROM SC WHERE SC.Sno = Student.Sno AND SC.Cno = 'C001' );

两种写法结果一样，但对新手来说性能差别很大：IN 子查询先执行子查询生成结果集，再和外层比较；EXISTS 是逐行扫描外层表，到内层验证是否存在。数据量小时感受不到，SC 表超过十万行时 EXISTS 通常更快，前提是 SC 表有索引。实验报告里把这两种写法都跑一遍，并比较执行时间，是对“查询优化”知识点最好的呼应。

3.4 实验四：视图是保存的查询，索引要建在刀刃上

视图实验的核心结论就一句话：视图不存数据，只是一条保存起来的 SELECT。教材通常会要求基于单表或两表建视图：

CREATE VIEW V_CS_Student AS SELECT Sno, Sname, Sage FROM Student WHERE Sdept = '计算机系'; GO SELECT * FROM V_CS_Student;

视图建好后可以像表一样查询，但它的数据实时来自基表。如果后续 UPDATE Student 把某个学生的 Sdept 改成数学系，再查询视图时这条记录自动消失；这是“视图更新时基表联动”的直接体现，也是实验报告里写“视图是虚拟表”的证据。

索引实验要从执行计划里看效果，而不是只看有没有建成功：

CREATE INDEX IX_SC_Grade ON SC(Grade); SET STATISTICS IO ON; SELECT * FROM SC WHERE Grade BETWEEN 80 AND 90; SET STATISTICS IO OFF;

逻辑说明：IX_SC_Grade 是在 Grade 列建的普通索引；SET STATISTICS IO ON 打开 IO 统计，执行完查询后消息面板会显示“扫描计数”“逻辑读取次数”。没索引时是全表扫描，逻辑读取等于该表所在数据页数量；建索引后通常是索引查找，逻辑读取大幅下降。报告里把前后两个数字放一起，索引的价值就量化了。

为什么说索引要建在刀刃上：WHERE 和 JOIN 的列适合建索引，而 SELECT 出来的列建索引往往浪费；一个表最多建个五六个索引，写操作频繁的表建更多反而拖慢更新，因为每次增删改都要同步维护索引结构。这是删掉废话后真正有信息量的选择逻辑。

4. 事务与权限实验：教科书里一笔带过，期末却爱考的 20 分

很多同学把实验一到实验四做得漂漂亮亮，却在实验五、实验六翻车。原因很简单：事务和权限这两章不写 SQL 语句看不出效果，必须在 SSMS 里手动开两个查询窗口，一个模拟用户 A，一个模拟用户 B，来回切换才能演示。准备实验前，把下面几个概念先盘清楚。

4.1 事务的三个关键词：BEGIN TRAN、COMMIT、ROLLBACK

事务实验最经典的设计是模拟银行转账：从张三账户扣 100，往李四账户加 100。教科书里通常只给你前半段，我自己复现时会把“中途断电”的场景补上，这也是老师最爱追问的“如果第二条语句失败怎么办”：

USE StudentDB; BEGIN TRANSACTION; UPDATE Account SET Balance = Balance - 100 WHERE AccountID = 'A001'; -- 模拟第二条语句失败：李四账户不存在 UPDATE Account SET Balance = Balance + 100 WHERE AccountID = 'B999'; IF @@ERROR <> 0 BEGIN ROLLBACK TRANSACTION; PRINT '转账失败，已回滚'; END ELSE BEGIN COMMIT TRANSACTION; PRINT '转账成功，已提交'; END

逻辑说明：BEGIN TRANSACTION 开启事务，两条 UPDATE 作为一个整体；第二条更新一个不存在的账户，影响行数为 0，但 @@ERROR 不一定非零，所以更稳的判断是用 @@ROWCOUNT 判断影响行数。上面用 @@ERROR 的方式只是教材演示，实际项目里要拿 @@ROWCOUNT >= 1 作为成功条件。ROLLBACK 之后，第一条 UPDATE 的扣款也会撤销。

参数说明：@@ERROR 是前一条 SQL 的错误号，0 表示成功；@@ROWCOUNT 是前一条语句影响的行数。两者都是会话级变量，用完即失效，所以要在关键语句后立即取值判断。

事务隔离级别是这张实验的另一个隐藏得分点。教材会给四个级别：读未提交、读已提交、可重复读、可串行化。我在实验报告里的演示脚本是这样的：

-- 窗口 A：开启事务但不提交 USE StudentDB; BEGIN TRANSACTION; UPDATE Account SET Balance = 500 WHERE AccountID = 'A001'; -- 此时不执行 COMMIT，保持事务打开 -- 窗口 B：默认隔离级别下查询 SET TRANSACTION ISOLATION LEVEL READ COMMITTED; SELECT Balance FROM Account WHERE AccountID = 'A001';

如果窗口 B 在 READ COMMITTED 下查询，会因为 A 的事务未提交而一直阻塞等待，直到 A 提交或回滚才返回结果；如果窗口 B 改成 READ UNCOMMITTED，能立刻读到 A 修改但未提交的 500，也就是脏读。这个阻塞和脏读的对照，比任何文字都直观，也是期末考试简答题“解释脏读”的标准实验证据。

4.2 权限控制：GRANT、REVOKE、DENY 的优先级要分清

权限实验通常要求创建两个用户：一个只读用户，一个可更新用户。先创建登录名和数据库用户：

USE master; CREATE LOGIN U_Read WITH PASSWORD = 'Read@123'; USE StudentDB; CREATE USER U_Read FOR LOGIN U_Read; GRANT SELECT ON Student TO U_Read; GRANT SELECT ON SC TO U_Read;

这段操作分两层：CREATE LOGIN 在 master 库创建服务器级登录名，CREATE USER 把登录名映射为 StudentDB 的数据库用户；GRANT SELECT 逐表授权。没有映射的话，登录名能连上服务器但进不了库，报“无法访问数据库 StudentDB”，这是权限实验最典型的翻车点。

撤销权限和禁止权限的顺序也容易踩坑。SQL Server 的权限判断顺序是 DENY > REVOKE > GRANT，也就是说即使用户同时拥有 GRANT 和 DENY，DENY 生效。演示脚本可以这样写：

-- 先给权限 GRANT UPDATE ON SC TO U_Read; -- 再禁止 DENY UPDATE ON SC TO U_Read; -- 验证：下面这条用 U_Read 登录执行会报错 -- UPDATE SC SET Grade = 60 WHERE Sno = '20230001';

逻辑说明：GRANT 之后 U_Read 有 UPDATE 权限，执行 UPDATE 成功；加 DENY 之后，即使之前有 GRANT，UPDATE 也被拒绝，报权限不足。这个“DENY 优先”的机制常混在选择题里考。

做权限实验时有一个习惯值得养成：每授予一个权限，就开一个新的查询窗口用对应登录名执行一次验证语句。权限不是写在语法上，而是写在“谁、对什么对象、能做什么操作”的三元组里，只有实测能证明权限真的生效。

4.3 存储过程实验：把事务和业务规则包在一个调用里

后半个学期的实验通常会把存储过程和触发器加进来。存储过程不过是把一串 SQL 命名保存，但它的得分点是“输入参数 + 事务 + 错误处理”三件套。下面这段脚本是我在教学项目里反复用的模板，也能直接放进实验报告：

CREATE PROCEDURE sp_Transfer @FromAccount CHAR(10), @ToAccount CHAR(10), @Amount DECIMAL(10,2) AS BEGIN BEGIN TRY BEGIN TRANSACTION; UPDATE Account SET Balance = Balance - @Amount WHERE AccountID = @FromAccount; IF @@ROWCOUNT = 0 THROW 50001, '转出账户不存在', 1; UPDATE Account SET Balance = Balance + @Amount WHERE AccountID = @ToAccount; IF @@ROWCOUNT = 0 THROW 50002, '转入账户不存在', 1; COMMIT TRANSACTION; END TRY BEGIN CATCH ROLLBACK TRANSACTION; THROW; END CATCH END GO EXEC sp_Transfer 'A001', 'B001', 100;

参数说明：三个输入参数分别表示转出账户、转入账户、金额；THROW 50001 是自定义错误号，50001 到 2147483647 之间可以自定义；BEGIN TRY/CATCH 捕获异常后强制回滚。执行 EXEC 调用时如果转入账户不存在，会看到业务错误“转入账户不存在”，且转出账户的扣款被回滚，可以查表验证。

存储过程实验有一个容易被忽略的细节：设计参数时不能只想着“能跑通”，要设计边界值。比如金额传 0 或负数，上面的过程并不会拦截，需要额外加 IF @Amount <= 0 THROW；把边界判断补上再提交，报告的说服力完全不同。

5. 实验避坑：五个让平时分缩水的经典翻车现场

数据库实验的扣分点往往不在 SQL 语法，而在于环境、字符集、提交状态这些看起来跟代码无关的细节。以下是踩过的五个坑，每条都按现象、原因、解决写清楚。

5.1 现象：中文显示成问号或乱码

做数据更新实验时，INSERT 中文姓名后 SELECT 查出来是“??”或“鏉庡洓”。原因是客户端和数据库的字符集不一致：SQL Server 安装时排序规则选了 Latin1_General，而客户端用 UTF-8 发送数据，入库时按错误代码页解释。解决方法是先查默认排序规则，再在库级别强制使用中文排序规则：

-- 查看当前排序规则 SELECT SERVERPROPERTY('Collation'); -- 建库时显式指定 CREATE DATABASE StudentDB COLLATE Chinese_PRC_CI_AS;

注意，改库排序规则要在建库时一次性搞定，已经建好的库改排序规则容易导致索引失效；如果实验指导里没提字符集，建库语句里加上 COLLATE Chinese_PRC_CI_AS 是保险做法。

5.2 现象：删除父表行时提示外键冲突，删不掉

实验二要求删除某个学生记录，DELETE FROM Student WHERE Sno='20230001' 报错“与外键约束冲突”。原因是 SC 表里还存着这个学生的选课记录，外键约束不允许删除被引用的父行。正确顺序是先在子表删除选课记录，再删学生：

DELETE FROM SC WHERE Sno = '20230001'; DELETE FROM Student WHERE Sno = '20230001';

如果实验指导明确写了要演示“受外键约束不能删除”，那这个报错本身就是得分点，把报错截图放进报告里并在旁边解释原因即可；如果没写，就按上面的顺序操作，避免白白扣印象分。

5.3 现象：视图创建成功，但 SELECT 视图报“对象名无效”

在 SSMS 里 CREATE VIEW 提示成功，关闭查询窗口后再次查询 V_CS_Student 却报对象名无效。原因是视图建在了别的数据库下，最常见的是 USE StudentDB 没有执行，CREATE VIEW 默认建在 master 库；关闭窗口后再连默认库还是 master，自然找不到。解决方法是创建视图前检查当前库，或者把库名写进查询：

USE StudentDB; GO SELECT * FROM dbo.V_CS_Student;

dbo. 前缀的作用是限定架构，避免在非 dbo 架构下查询时找不到对象；加了 dbo. 前缀后，即便当前库不对也会立即报错而不是“不报错但查不到”。

5.4 现象：事务没提交，关闭窗口后数据“消失”

更新操作执行完，消息面板显示“影响 1 行”，但重新打开一个查询窗口查询却发现数据没变。原因是上一个窗口执行了 BEGIN TRANSACTION 之后忘记 COMMIT，关闭窗口时数据库自动回滚了未提交事务。解决方法是检查每个 BEGIN 是否有对应的 COMMIT 或 ROLLBACK，最好的习惯是写完事务代码立即把 COMMIT 写上，再补中间的语句：

BEGIN TRANSACTION; UPDATE Account SET Balance = 100 WHERE AccountID = 'A001'; COMMIT TRANSACTION;

我一般会在事务代码上方加一行注释“写完就提交，绝不让事务挂到窗口关闭”，这是避免假数据丢失的笨但有效的方法。

5.5 现象：权限授予后，另一登录名仍无法访问数据库

GRANT SELECT 成功执行，但用另一个登录名连接时仍报“无法访问数据库 StudentDB”。原因是只创建了登录名，没创建数据库用户映射；GRANT 是授予数据库用户的，而登录名连进库之前必须先有 USER 映射。检查脚本是否包含两条配套语句：

CREATE USER U_Read FOR LOGIN U_Read; GRANT SELECT ON Student TO U_Read;

没有第一条，第二条就是空操作。这属于数据库安全模型里“登录名（服务器级）和用户名（数据库级）”分离的设计，报告里把“先映射后授权”这个顺序写清楚，能避开一半权限类扣分。

6. 把六个实验串成一个验收脚本：一个能自测的收尾技巧

最后一个建议，不是再多写一道题，而是把所有实验脚本合并成一个能从零跑通的验收脚本。我用一个起名 DBLab_CheckAll 的文件，把建库、建表、插入、查询、视图、索引、事务、权限全部按顺序放进去，每段后面加 PRINT 输出阶段标记。这样每次实验前跑一遍，就知道哪些环节被误删改过。

验收脚本的关键是按“依赖顺序”排列：建库先于建表，建表先于插入，插入先于查询。任意一步失败，后面的脚本会连锁报错，但 PRINT 标记会把失败点定位到具体阶段。比如 PRINT 'STEP2 建表完成' 之后如果报错，一定出在建表阶段。

我个人的习惯是，验收脚本里故意保留一个“可注释掉的危险语句”区域，比如不带 WHERE 的 UPDATE、不带 COMMIT 的事务；跑通后把它注释掉，在下一次实验前再恢复，用来测试自己是不是真的理解每条语句的作用。

这个技巧来自一次实际教训：某次我连续做了三次实验，最后一次改动了一个表的字段类型，结果前面实验的视图和存储过程全部失效，但因为没有统一脚本，直到要交报告时才一条一条排查，白耗了一晚上。从那以后，每次实验结束前我都强制走一遍 DBLab_CheckAll，确认前面所有章节的实验还能正常工作。希望帮到你。

本文还有配套的精品资源，点击获取