SQL Server教室信息管理系统：数据库层冲突检测与并发控制

简介：面向高校数据库课程设计与SQL Server入门实践的教室信息管理系统脚本包，聚焦教室设备报修登记、教室使用计划与课程安排关联等常见管理问题，适合计算机专业学生、数据库初学者及需要课程设计选题参考的读者。压缩包共6个SQL文件，约11KB，内容以建库建表脚本为主，可用于在SQL Server中快速还原数据库结构，并围绕教室、设备、使用记录等核心数据表开展增删改查与约束练习。已有2374人学习下载，说明其作为轻量级课程设计素材具有一定参考价值。读者可借助脚本梳理实体关系与字段设计，理解主外键、完整性约束及基础查询的写法，也可在此基础上补充存储过程、视图或前端交互，形成更完整的课程设计成果，适合用作选题原型与数据库实验素材。

1. 一间教室被两个人同时选中：这个课程设计要挡住的到底是什么

教室借用最怕的不是没教室，是两个人同时看上了同一间。某高校做数据库课程设计的 A 同学，第一次预答辩被问住的不是界面漂不漂亮，而是「两个学生同一秒提交同一间教室同一时段的申请，你的系统怎么办」。这套基于 SqlServer 的教室信息管理系统，核心就干了这一件事：把教室、时间片、申请单、用户四类数据落成表，用约束、索引和事务把「抢教室」挡在 database 层。它适合正在找课程设计骨架、需要能跑通也讲得清的人，也适合刚接手场地预约类小系统、想看别人怎么在数据库层做冲突检测的开发者。这份综合资源的重心不在页面，在表结构和那几条关键 SQL。

2. 拆表结构：四张核心表怎么撑起教室信息管理

2.1 为什么拆成「教室 / 时间片 / 申请单 / 用户」而不是一张大表

新手最容易走的路是把所有字段铺成一张表：教室号、楼名、容量、申请人、日期、开始节次、结束节次、用途、状态，全塞进去。演示阶段看着挺顺，一旦要改「三号楼的 302 改名叫 A302」，就得 UPDATE 几百行；一旦要统计「这学期每间教室被用了多少节」，就得在字符串字段上做切割。这是典型的把维度数据和事实数据揉在一起。

我一般按星型模型的思路切：Classroom（教室）和TimeSlot（节次）是维度表，RoomApplication（申请单）是事实表，AppUser是主体表。楼栋要不要单独拆一张Building？如果只是课设规模，楼名可以直接放教室表；但只要你需要「按楼统计利用率」「按楼筛选教室」，拆出来更省事，也不容易写错 GROUP BY。我倾向于拆，因为它只多一次 JOIN，却让后面所有报表查询都变干净。

用户表这里有个取舍：学生、教师、管理员是分三张表还是一张表加角色码？分开建三张表在范式上没错，但申请单的外键就得写三个可空列加一个类型判断，查询时要 UNION，课程设计的体量完全没必要。单表加RoleCode是常见做法，代价是角色相关字段会有一部分为空，用 CHECK 约束兜住就行。

还有一个容易被忽略的：学期。很多同学把学期写死成查询条件，结果换个学期数据全乱。我的习惯是在申请单上加TermId或者干脆用ApplyDate的范围来界定，前者更严谨，后者更省表。课设用后者够了，但要在文档里讲清楚这个决定的边界。

2.2 建库建表脚本：约束写在 DDL 里，别指望前端校验

下面这段脚本可以直接在 SSMS 或者 sqlcmd 里跑，注意CREATE DATABASE和后续语句之间必须有GO，否则解析器会在库还没建出来的时候就去解析表名。

CREATE DATABASE ClassroomMS; GO USE ClassroomMS; GO -- 楼栋：拆出来是为了按楼统计 CREATE TABLE dbo.Building ( BuildingId INT IDENTITY(1,1) NOT NULL PRIMARY KEY, BuildingName NVARCHAR(30) NOT NULL, CONSTRAINT UQ_Building_Name UNIQUE (BuildingName) ); GO CREATE TABLE dbo.Classroom ( RoomId INT IDENTITY(1,1) NOT NULL PRIMARY KEY, RoomNo NVARCHAR(20) NOT NULL, BuildingId INT NOT NULL, Capacity SMALLINT NOT NULL, RoomType TINYINT NOT NULL CONSTRAINT DF_Room_Type DEFAULT (1), -- 1普通 2多媒体 3机房 HasProjector BIT NOT NULL CONSTRAINT DF_Room_Proj DEFAULT (0), IsActive BIT NOT NULL CONSTRAINT DF_Room_Active DEFAULT (1), CONSTRAINT FK_Room_Building FOREIGN KEY (BuildingId) REFERENCES dbo.Building (BuildingId), CONSTRAINT UQ_Room_No UNIQUE (BuildingId, RoomNo), -- 楼内房号唯一，不是全局唯一 CONSTRAINT CK_Room_Capacity CHECK (Capacity BETWEEN 1 AND 500), CONSTRAINT CK_Room_Type CHECK (RoomType IN (1, 2, 3)) ); GO CREATE TABLE dbo.TimeSlot ( SlotId TINYINT NOT NULL PRIMARY KEY, -- 1..12 SlotName NVARCHAR(20) NOT NULL, StartMin SMALLINT NOT NULL, -- 距 00:00 的分钟数 EndMin SMALLINT NOT NULL, CONSTRAINT CK_Slot_Range CHECK (StartMin >= 0 AND EndMin <= 1440 AND StartMin < EndMin) ); GO CREATE TABLE dbo.AppUser ( UserId INT IDENTITY(1,1) NOT NULL PRIMARY KEY, LoginName NVARCHAR(32) NOT NULL, DisplayName NVARCHAR(30) NOT NULL, RoleCode TINYINT NOT NULL, -- 1学生 2教师 3管理员 DeptName NVARCHAR(50) NULL, CONSTRAINT UQ_User_Login UNIQUE (LoginName), CONSTRAINT CK_User_Role CHECK (RoleCode IN (1, 2, 3)) ); GO CREATE TABLE dbo.RoomApplication ( AppId BIGINT IDENTITY(1,1) NOT NULL PRIMARY KEY, RoomId INT NOT NULL, UserId INT NOT NULL, ApplyDate DATE NOT NULL, -- 用 DATE 不用 DATETIME，省掉一堆边界坑 StartSlot TINYINT NOT NULL, EndSlot TINYINT NOT NULL, Purpose NVARCHAR(100) NOT NULL, StatusCode TINYINT NOT NULL CONSTRAINT DF_App_Status DEFAULT (0), -- 0待审 1通过 2驳回 3取消 CreatedAt DATETIME2(0) NOT NULL CONSTRAINT DF_App_Created DEFAULT (SYSDATETIME()), CONSTRAINT FK_App_Room FOREIGN KEY (RoomId) REFERENCES dbo.Classroom (RoomId), CONSTRAINT FK_App_User FOREIGN KEY (UserId) REFERENCES dbo.AppUser (UserId), CONSTRAINT FK_App_SlotS FOREIGN KEY (StartSlot) REFERENCES dbo.TimeSlot (SlotId), CONSTRAINT FK_App_SlotE FOREIGN KEY (EndSlot) REFERENCES dbo.TimeSlot (SlotId), CONSTRAINT CK_App_SlotOrder CHECK (StartSlot <= EndSlot), CONSTRAINT CK_App_Status CHECK (StatusCode IN (0, 1, 2, 3)) ); GO

几个参数值得单独说。UQ_Room_No UNIQUE (BuildingId, RoomNo)是复合唯一约束，意思是「同一栋楼里房号不能重复」，跨楼可以都叫 302，这符合真实场景；如果写成全局唯一，某高校两栋楼各有一个 302 就插不进去了。ApplyDate明确用DATE，是因为后面所有冲突判断都基于「同一天」，用DATETIME会把2025-10-15 08:00和2025-10-15 00:00当成两天，这个坑我在第 5 章会再拆一次。StatusCode IN (0,1,2,3)这种小整型枚举比字符串状态好，索引窄、比较快，前端做映射就行。

StartSlot/EndSlot的外键指向同一张TimeSlot表，这是自引用式的两次外键，语法上没问题，但要保证插入时两个值都存在于TimeSlot里。CK_App_SlotOrder挡住「开始节次大于结束节次」这种明显错误，属于花一秒钟写、省半小时排查的约束。

2.3 节次建模：整数、分钟数还是时间类型

这是整个设计里最容易做错、后面又最难改的地方。三种常见方案，我按课设的实际情况给个对比。

课设场景我建议节次编号，理由是答辩时老师问「第 3-4 节被占用了吗」，你能直接用StartSlot <= 4 AND EndSlot >= 3回答，思路一目了然。分钟偏移更适合真实排课系统，因为它要处理「上午第二大节其实是 9:55 到 11:30」这种非均匀切片。

不管选哪种，TimeSlot表都要把StartMin/EndMin存下来，哪怕当前不用。原因是将来要做「两个时间片是否重叠」的校验、或者要做「按小时统计使用率」，没有分钟数就只能硬编码。这张表还有个隐含价值：它把「学校到底分几节」这件事变成了数据，而不是散落在代码里的魔法数字。

提示：TimeSlot的种子数据建议用MERGE或者IF NOT EXISTS包起来，重复执行脚本不会主键冲突，这在反复重建环境的课设里能省很多事。

2.4 索引：冲突检测那条 SQL 决定索引怎么建

索引不是「主键建完就完事」。这个系统里 90% 的性能问题都集中在一条 SQL 上——判断某教室某天某时段有没有被占。它的 WHERE 条件大致是RoomId = ? AND ApplyDate = ? AND StatusCode IN (0,1) AND StartSlot <= ? AND EndSlot >= ?，那么索引就应该按等值列在前、范围列在后的顺序排。

-- 等值列在前：RoomId、ApplyDate、StatusCode -- 范围列放 INCLUDE，避免回表 CREATE INDEX IX_App_Room_Date_Status ON dbo.RoomApplication (RoomId, ApplyDate, StatusCode) INCLUDE (StartSlot, EndSlot, UserId, Purpose); GO -- 报表用：按日期范围扫通过状态的申请 CREATE INDEX IX_App_Date_Status ON dbo.RoomApplication (ApplyDate, StatusCode) INCLUDE (RoomId, StartSlot, EndSlot); GO

INCLUDE里的列不参与排序，只是随索引页一起存，作用是让查询计划走「索引覆盖」而不回表。课设数据量通常只有几千行，回不回表其实没差别，但答辩时你能指着执行计划说「这里是 Index Seek 不是 Table Scan」，这个细节很加分。

StatusCode放进索引键而不是 INCLUDE，是因为它在 WHERE 里是等值条件，参与定位更有效。如果只想索引「待审 + 通过」这两种状态，可以用筛选索引：

CREATE INDEX IX_App_Active ON dbo.RoomApplication (RoomId, ApplyDate, StartSlot, EndSlot) WHERE StatusCode IN (0, 1);

筛选索引体积更小、更贴合冲突检测，代价是统计信息和参数化查询有时会绕开它，写的时候要确认查询条件里带了同样的谓词。这个细节属于「知道就好、不必强上」的范畴。

3. 冲突检测落到数据库层：一条存储过程解决「抢教室」

3.1 时间区间重叠的判定条件，只有一种写法是对的

两个区间[a1, a2]和[b1, b2]重叠的充要条件是a1 <= b2 AND a2 >= b1。就这一行，很多同学会写成四种情况全列出来（包含、被包含、左交、右交），写完全漏一种。用这个不等式，四种情况全覆盖。

放到表上，判断「新申请与已有申请冲突」就是：

SELECT 1 FROM dbo.RoomApplication WHERE RoomId = @RoomId AND ApplyDate = @ApplyDate AND StatusCode IN (0, 1) -- 待审和通过都算占用，驳回和取消不算 AND StartSlot <= @EndSlot -- 已有开始 <= 新结束 AND EndSlot >= @StartSlot; -- 已有结束 >= 新开始

这里有三个容易翻车的点。第一，StatusCode的取值集合决定了「什么算占用」，如果只写= 1，待审的申请就不占位，两个人都能提交成功，审核时才发现撞车。第二，<=和>=必须带等号，否则「第 3 节」和「第 3 节」不算冲突，这是最典型的边界错误。第三，这个查询本身没错，错在它和后面的 INSERT 是两条独立语句——两条语句之间有时间窗，并发下依然会双写成功。

注意：只要冲突判断和插入不在同一个事务里，也不带锁提示，这段 SQL 在并发下就只是「看着对」。

3.2 存储过程 + 事务：把「查-判-插」压成原子操作

把上面这段逻辑封进存储过程，加上显式事务和UPDLOCK, HOLDLOCK，才是能扛住并发的版本。

CREATE OR ALTER PROCEDURE dbo.usp_SubmitApplication @RoomId INT, @UserId INT, @ApplyDate DATE, @StartSlot TINYINT, @EndSlot TINYINT, @Purpose NVARCHAR(100) AS BEGIN SET NOCOUNT ON; SET XACT_ABORT ON; -- 出错自动回滚，少写一层判断 IF @StartSlot > @EndSlot THROW 50001, N'开始节次不能大于结束节次', 1; BEGIN TRY BEGIN TRANSACTION; -- UPDLOCK：锁住读到的行，别人不能同时改 -- HOLDLOCK：锁保持到事务结束，等价于 SERIALIZABLE 的范围锁 IF EXISTS ( SELECT 1 FROM dbo.RoomApplication WITH (UPDLOCK, HOLDLOCK) WHERE RoomId = @RoomId AND ApplyDate = @ApplyDate AND StatusCode IN (0, 1) AND StartSlot <= @EndSlot AND EndSlot >= @StartSlot ) BEGIN ROLLBACK TRANSACTION; THROW 50002, N'该时段已被占用，请换一间教室或换时间', 1; END INSERT INTO dbo.RoomApplication (RoomId, UserId, ApplyDate, StartSlot, EndSlot, Purpose, StatusCode) VALUES (@RoomId, @UserId, @ApplyDate, @StartSlot, @EndSlot, @Purpose, 0); COMMIT TRANSACTION; SELECT SCOPE_IDENTITY() AS NewAppId; END TRY BEGIN CATCH IF XACT_STATE() <> 0 ROLLBACK TRANSACTION; THROW; -- 保留原始错误号，前端好分类处理 END CATCH END GO

逐段说清楚。SET XACT_ABORT ON让运行时错误自动回滚整个事务，避免事务悬着不提交，把锁一直挂在那儿。UPDLOCK的作用是「我读这些行是为了后面要写」，所以拿的是更新锁而不是共享锁，两个会话不会同时拿到；HOLDLOCK把锁的持有期延长到事务结束，没有它，锁在读完之后立刻释放，等于白锁。

IF EXISTS里再ROLLBACK然后THROW，是刻意这么写的：先把事务干净地结束，再抛异常，避免 CATCH 里重复回滚。CATCH 块里IF XACT_STATE() <> 0这一句不能省，因为有些错误（比如批处理中止）会让事务处于「不可提交」状态，直接ROLLBACK会报另一个错，把真正的错误信息盖掉。

SCOPE_IDENTITY()而不是@@IDENTITY，因为后者会被触发器里的插入干扰，返回错误的 ID。这是个经典问题，答辩时提一句能体现你确实踩过。

调用方式：

EXEC dbo.usp_SubmitApplication @RoomId = 3, @UserId = 7, @ApplyDate = '20251015', @StartSlot = 3, @EndSlot = 4, @Purpose = N'数据库课程设计小组讨论';

日期参数写成'20251015'而不是'2025-10-15'，是为了绕开语言设置导致yyyy-mm-dd被解析成yyyy-dd-mm的歧义——这个坑在DATE类型上影响较小，但在DATETIME上会直接把月份和日期对调，且不报错。

3.3 隔离级别和锁提示怎么选：READ COMMITTED 到底够不够

默认的 READ COMMITTED 能防脏读，防不住「两边都读到没人占，然后都插入」。把隔离级别提到 SERIALIZABLE 也能解决，但它是给整个事务加范围锁，影响面比HOLDLOCK大，容易把不相关的查询也拖进阻塞。下面这张表是我在几个类似系统里试过之后的结论。

SNAPSHOT 那一行值得展开：它让读不阻塞写、写不阻塞读，很多人以为这是万能方案，但在「先读后写」的冲突检测里，两个事务读到的都是自己开始时的快照，谁都看不到对方未提交的插入，结果就是双双通过检测。启用 SNAPSHOT 的库必须额外准备硬约束，否则只是把问题推迟到数据不一致。

3.4 用唯一索引兜底：把「一次申请」拆成「每节一行」

锁提示解决的是「大概率」，唯一索引解决的是「绝对」。但(RoomId, ApplyDate, StartSlot, EndSlot)这种四列组合唯一约束挡不住「3-4 节」和「4-5 节」的重叠，因为区间端点不一样。想用唯一索引硬约束，就得改变粒度：申请单存一行，同时往RoomSlotOccupancy里按节次展开写 N 行。

CREATE TABLE dbo.RoomSlotOccupancy ( RoomId INT NOT NULL, ApplyDate DATE NOT NULL, SlotId TINYINT NOT NULL, AppId BIGINT NOT NULL, CONSTRAINT PK_Occupancy PRIMARY KEY (RoomId, ApplyDate, SlotId), -- 主键即唯一约束 CONSTRAINT FK_Occ_App FOREIGN KEY (AppId) REFERENCES dbo.RoomApplication (AppId) );

主键(RoomId, ApplyDate, SlotId)天然保证「同一间教室同一天同一节只能有一条占用记录」，第二个人插入时直接主键冲突，事务回滚，一行代码都不用判。代价是写放大：一次 4 节的申请要插 4 行，取消时也要同步删。课设规模完全承受得起，而且这个设计在答辩时非常好讲——「冲突检测从业务逻辑变成了数据结构约束」。

4. 查询与报表：答辩现场真正会被追问的几条 SQL

4.1 组合条件加分页：顺手把参数嗅探按住

后台列表页通常是「日期 + 楼栋 + 状态 + 关键字」四个可选条件加翻页。最直接的写法是拼动态 SQL，但课设里更容易出彩的是参数化 +OFFSET FETCH，同时用OPTION (RECOMPILE)规避参数嗅探。

CREATE OR ALTER PROCEDURE dbo.usp_QueryApplications @ApplyDate DATE = NULL, @BuildingId INT = NULL, @StatusCode TINYINT = NULL, @Keyword NVARCHAR(50) = NULL, @PageIndex INT = 1, @PageSize INT = 20 AS BEGIN SET NOCOUNT ON; IF @PageSize > 100 SET @PageSize = 100; -- 防止前端传个 10000 把库拖死 IF @PageIndex < 1 SET @PageIndex = 1; SELECT a.AppId, b.BuildingName, r.RoomNo, u.DisplayName, a.ApplyDate, s1.SlotName AS StartSlotName, s2.SlotName AS EndSlotName, a.Purpose, a.StatusCode FROM dbo.RoomApplication a JOIN dbo.Classroom r ON r.RoomId = a.RoomId JOIN dbo.Building b ON b.BuildingId = r.BuildingId JOIN dbo.AppUser u ON u.UserId = a.UserId JOIN dbo.TimeSlot s1 ON s1.SlotId = a.StartSlot JOIN dbo.TimeSlot s2 ON s2.SlotId = a.EndSlot WHERE (@ApplyDate IS NULL OR a.ApplyDate = @ApplyDate) AND (@BuildingId IS NULL OR r.BuildingId = @BuildingId) AND (@StatusCode IS NULL OR a.StatusCode = @StatusCode) AND (@Keyword IS NULL OR a.Purpose LIKE N'%' + @Keyword + N'%') ORDER BY a.ApplyDate DESC, a.StartSlot ASC, a.AppId DESC OFFSET (@PageIndex - 1) * @PageSize ROWS FETCH NEXT @PageSize ROWS ONLY OPTION (RECOMPILE); END GO

@X IS NULL OR col = @X这种「万能条件」写法，好处是一条 SQL 覆盖所有组合，坏处是执行计划会被第一次调用的参数形态固定住——第一次传了@BuildingId = 3，后面传 NULL 时可能还在用同一个计划。OPTION (RECOMPILE)让每次执行重新编译，代价是编译开销，对课设这点并发完全值得。生产环境里更讲究的做法是动态 SQL 拼 WHERE 或者用OPTION (OPTIMIZE FOR UNKNOWN)，但那是另一个话题。

ORDER BY里带了a.AppId DESC，是为了让排序键唯一，否则同一时刻插入的多条记录顺序不稳定，翻页时会出现「第 2 页又看到第 1 页的记录」。这个现象叫不确定排序，很多人以为是前端 bug。

4.2 单间教室的周课表：不用 PIVOT 也能行转列

周课表是这类系统的门面功能，也是答辩必看。PIVOT语法能用，但它的列必须写死，一旦要改成「显示两周」就得重写，而且嵌套查询可读性差。我一般用CASE WHEN + MAX手写行转列，可控性强得多。

DECLARE @Day DATE = '2025-10-15'; -- 以 1900-01-01（周一）为基准算出本周周一，不受 DATEFIRST 设置影响 DECLARE @Monday DATE = DATEADD(DAY, -(DATEDIFF(DAY, CONVERT(DATE, '19000101'), @Day) % 7), @Day); DECLARE @RoomId INT = 3; SELECT s.SlotId, s.SlotName, MAX(CASE WHEN DATEDIFF(DAY, @Monday, a.ApplyDate) = 0 THEN a.Purpose END) AS [周一], MAX(CASE WHEN DATEDIFF(DAY, @Monday, a.ApplyDate) = 1 THEN a.Purpose END) AS [周二], MAX(CASE WHEN DATEDIFF(DAY, @Monday, a.ApplyDate) = 2 THEN a.Purpose END) AS [周三], MAX(CASE WHEN DATEDIFF(DAY, @Monday, a.ApplyDate) = 3 THEN a.Purpose END) AS [周四], MAX(CASE WHEN DATEDIFF(DAY, @Monday, a.ApplyDate) = 4 THEN a.Purpose END) AS [周五], MAX(CASE WHEN DATEDIFF(DAY, @Monday, a.ApplyDate) = 5 THEN a.Purpose END) AS [周六], MAX(CASE WHEN DATEDIFF(DAY, @Monday, a.ApplyDate) = 6 THEN a.Purpose END) AS [周日] FROM dbo.TimeSlot s LEFT JOIN dbo.RoomApplication a ON a.StartSlot <= s.SlotId -- 关键：一次申请覆盖多节，要展开 AND a.EndSlot >= s.SlotId AND a.RoomId = @RoomId AND a.StatusCode = 1 AND a.ApplyDate BETWEEN @Monday AND DATEADD(DAY, 6, @Monday) GROUP BY s.SlotId, s.SlotName ORDER BY s.SlotId;

a.StartSlot <= s.SlotId AND a.EndSlot >= s.SlotId这个 JOIN 条件，本质是把「3-4 节」这一条记录展开成两行，分别对上第 3 节和第 4 节。没有这个展开，连堂的课在课表上只会占一格，另一格空着，看着像 bug。

@Monday的算法用DATEDIFF从 1900-01-01 起算天数再取模 7，是因为DATEPART(WEEKDAY, ...)的结果依赖会话的DATEFIRST设置，换台机器可能周日的编号是 1 也可能是 7，课表整体错位一格。这个坑我在第 5 章展开。MAX对应GROUP BY，因为CASE里返回的是字符串，聚合必须有；实际上每天每节最多一条记录，MAX只是形式上满足语法。

4.3 利用率统计：分母写错，后面全废

「教室利用率」是老师最爱问的指标之一，因为它能一眼看出你懂不懂业务口径。利用率 = 实际占用节次 / 可排节次。分子好算，分母坑最多：可排节次是「教室数 × 天数 × 每天节次数」，还是「教室数 × 工作日数 × 每天节次数」？周末算不算？教室停用期间算不算？

DECLARE @FromDate DATE = '2025-09-01', @ToDate DATE = '2025-10-31'; ;WITH DayCount AS ( SELECT DATEDIFF(DAY, @FromDate, @ToDate) + 1 AS TotalDays -- 含首尾 ), Used AS ( SELECT a.RoomId, COUNT(*) AS ApplyCount, SUM(a.EndSlot - a.StartSlot + 1) AS UsedSlots FROM dbo.RoomApplication a WHERE a.StatusCode = 1 AND a.ApplyDate >= @FromDate AND a.ApplyDate < DATEADD(DAY, 1, @ToDate) -- 半开区间，避免时间边界 GROUP BY a.RoomId ) SELECT b.BuildingName, r.RoomNo, r.Capacity, ISNULL(u.ApplyCount, 0) AS ApplyCount, ISNULL(u.UsedSlots, 0) AS UsedSlots, CAST(100.0 * ISNULL(u.UsedSlots, 0) / NULLIF(d.TotalDays * 5.0, 0) AS DECIMAL(5,1)) AS UsageRatePct -- 每天按 5 个可排时段 FROM dbo.Classroom r JOIN dbo.Building b ON b.BuildingId = r.BuildingId CROSS JOIN DayCount d LEFT JOIN Used u ON u.RoomId = r.RoomId WHERE r.IsActive = 1 ORDER BY UsageRatePct DESC, r.RoomNo;

NULLIF(d.TotalDays * 5.0, 0)是防除零的标准写法，比CASE WHEN ... THEN ... END干净。5.0这个魔法数字代表每天可排时段数，实际项目里应该从TimeSlot表COUNT(*)出来，写死只是为了让这段查询能独立跑。半开区间>= @FromDate AND < DATEADD(DAY, 1, @ToDate)比BETWEEN安全，后者在列是DATETIME时会漏掉最后一天的绝大部分数据。

4.4 视图、执行计划：演示不卡的三件事

第一件，把高频的多表 JOIN 封成视图，前端只管SELECT * FROM vw_ApplicationDetail，字段变了改视图不改代码。视图不做物化，性能上和直接写 JOIN 一样，但可维护性差很多。

第二件，演示前用SET STATISTICS IO ON跑一遍主查询，看logical reads这个指标。课设数据量小，几百次逻辑读根本不慢，但如果某条查询 reads 上千，八成是缺索引或者隐式转换——比如NVARCHAR列拿VARCHAR参数去比，LIKE里没加N前缀，都会导致索引失效走扫描。

第三件，别在演示机上开「实际执行计划」跑大查询。图形化执行计划本身开销不小，几百毫秒的查询能拖到两三秒，评委看到的就是「你这系统好卡」。要看看「估计执行计划」，或者干脆用SET SHOWPLAN_ALL ON输出文本。

5. 排查实录：教室里跑不通的五种现场情况

5.1 连接和登录：能登进服务器，却打不开库

现象：在自己电脑上一切正常，拷到同学机器上，连接串没改，报「无法打开登录所请求的数据库 "ClassroomMS"。登录失败。」

原因：两种可能。一是目标机器上只还原了表结构脚本，没建库，Initial Catalog指向一个不存在的库；二是只建了登录名（Login）没建数据库用户（User），SQL Server 的「登录」和「数据库用户」是两层，登录成功不代表在某个库里有权限。用 sa 跑没问题、换成普通账号就报错，基本就是第二种。

解决：先确认库存在，再补用户映射。脚本化处理：

USE master; GO IF NOT EXISTS (SELECT 1 FROM sys.sql_logins WHERE name = 'cls_app') CREATE LOGIN cls_app WITH PASSWORD = N'ChangeMe_2025', CHECK_POLICY = OFF; GO USE ClassroomMS; GO IF NOT EXISTS (SELECT 1 FROM sys.database_principals WHERE name = 'cls_app') CREATE USER cls_app FOR LOGIN cls_app; GO ALTER ROLE db_datareader ADD MEMBER cls_app; ALTER ROLE db_datawriter ADD MEMBER cls_app; GO

顺带检查登录名的默认数据库，如果它指向一个已被删除的库，登录时也会报错：

ALTER LOGIN cls_app WITH DEFAULT_DATABASE = ClassroomMS;

5.2 并发：明明写了判断，还是插进去两条

现象：两个人同时点「提交申请」，冲突提示没弹出来，数据库里躺了两条同教室同时段的记录。手动重放一次又复现不了。

原因：冲突判断和 INSERT 是两条独立语句，中间有几十毫秒的窗口。两个会话都执行了IF EXISTS得到「不冲突」，然后各自插入，都成功。这不是 SQL 写错了，是没加锁、没事务。

解决：换成第 3 章那个存储过程，加WITH (UPDLOCK, HOLDLOCK)和显式事务。要验证是否真的修好了，开两个查询窗口，都先BEGIN TRANSACTION，第一个窗口执行到检测那步先不提交，第二个窗口执行同样的过程，会看到它被阻塞——这就说明锁生效了。验证完记得两边都ROLLBACK，别把测试数据留在库里。

5.3 并发二：加了锁提示反而死锁，或者整张表被锁住

现象：加了UPDLOCK, HOLDLOCK之后，偶尔报「事务被死锁牺牲」，或者明明只查一间教室，别的教室的申请也提交不了。

原因：冲突检测的 WHERE 条件上没有合适的索引，优化器只能全表扫描，HOLDLOCK的范围锁就落到了整张表（或者大量页）上。锁的范围由「实际读了多少」决定，不由「你想要多少」决定。另一个常见原因是两个存储过程加锁顺序不一致，比如一个先锁RoomApplication再锁RoomSlotOccupancy，另一个反过来。

解决：建第 2.4 节那条IX_App_Room_Date_Status，把RoomId、ApplyDate、StatusCode放进去，让冲突检测变成精确的 Index Seek，锁只落在命中的键范围上。所有写操作统一按「先主表后明细表」的顺序加锁。排查死锁用sys.dm_exec_requests找到被阻塞的会话，或者开 1222 跟踪标记把死锁图写进错误日志：

DBCC TRACEON (1222, -1); -- 全局开启，重启后失效，仅用于排查

5.4 日期与区域设置：查询少一天，课表错一格

现象：按日期查「10 月 15 日」的申请，查出来是空的，数据库里明明有；或者周课表在 A 同学机器上正常，换台机器整体错位一格。

原因：日期问题多半是把'2025-10-15'这种字符串传给DATETIME参数，在「日期格式为 dmy」的会话下被解析成 10 月 15 日之外的某一天，或者被解析失败但没报错。课表错位则是DATEPART(WEEKDAY, ...)依赖SET DATEFIRST，有的环境周日是 1，有的是 7。

解决：参数一律用DATE类型，字符串一律用'YYYYMMDD'这种无歧义格式，或者直接用DATEFROMPARTS(2025, 10, 15)。周几的计算改成以固定基准日取模：

-- 不依赖 DATEFIRST 的周一算法 DECLARE @Monday DATE = DATEADD(DAY, -(DATEDIFF(DAY, CONVERT(DATE, '19000101'), @Day) % 7), @Day);

建库时把排序规则明确写死，别依赖服务器默认值：

CREATE DATABASE ClassroomMS COLLATE Chinese_PRC_CI_AS;

5.5 迁移：换台机器，数据导进去就报外键冲突

现象：用「生成脚本」导出结构和数据，到新机器上执行，前半段成功，中间报「INSERT 语句与 FOREIGN KEY 约束冲突」。

原因：导出脚本里表的创建和数据的插入顺序是按表名或者对象 ID 排的，不保证父表先于子表。另外IDENTITY列带显式值插入时必须开SET IDENTITY_INSERT，否则报错或者自增序列错乱。

解决：按依赖顺序手动排——Building→Classroom→TimeSlot→AppUser→RoomApplication。带自增列的表插入前开开关：

SET IDENTITY_INSERT dbo.Classroom ON; -- 这里插带 RoomId 的数据 SET IDENTITY_INSERT dbo.Classroom OFF;

一个会话里同时只能有一张表处于IDENTITY_INSERT ON状态，插完立刻关，别图省事一直开着。导完还要把自增种子校准，否则下一条新数据会主键冲突：

DBCC CHECKIDENT ('dbo.RoomApplication', RESEED);

不带第二个参数时，它会把种子重置为当前最大值，这是最省心的用法。

6. 从能跑到能演示：一键部署脚本与答辩前自检

课设最容易翻车的环节不是写代码，是答辩当天在别人电脑上跑不起来。我后来固定用两个文件解决：一个deploy.sql，一个seed.sql，用 sqlcmd 串起来执行。

# -b：遇错立即返回非零退出码，别让脚本带着错误往下跑 # -I：开启 QUOTED_IDENTIFIER，建筛选索引和计算列时必需 sqlcmd -S localhost -U sa -P "YourPwd" -b -I -i .\sql\01_schema.sql sqlcmd -S localhost -U sa -P "YourPwd" -b -I -i .\sql\02_seed.sql sqlcmd -S localhost -U sa -P "YourPwd" -b -I -Q "USE ClassroomMS; EXEC dbo.usp_SelfCheck;"

-b这个参数很多人不加，结果建表失败、脚本继续跑，最后报一堆「对象不存在」，真正的原因被淹在几百行输出里。-I则是筛选索引的硬性要求，不开会直接报「CREATE INDEX 失败，因为 SET 选项不正确」。

自检存储过程里放几条断言式查询，跑完一眼能看出环境对不对：

CREATE OR ALTER PROCEDURE dbo.usp_SelfCheck AS BEGIN SET NOCOUNT ON; SELECT '教室数' AS Item, COUNT(*) AS Cnt FROM dbo.Classroom UNION ALL SELECT '时段数', COUNT(*) FROM dbo.TimeSlot UNION ALL SELECT '申请数', COUNT(*) FROM dbo.RoomApplication UNION ALL SELECT '冲突数据(应为0)', COUNT(*) FROM ( SELECT RoomId, ApplyDate, StartSlot FROM dbo.RoomApplication WHERE StatusCode IN (0,1) GROUP BY RoomId, ApplyDate, StartSlot HAVING COUNT(*) > 1 ) t; END

最后那条「冲突数据」检查是核心。只要它不为 0，说明数据层已经出现超订，不管界面多漂亮都别上台演示。答辩前我会把它连同「学生账号能不能登录」「能不能提交一条跨节次申请」「取消后能不能重新申请同一时段」这三条手工用例一起走一遍，五分钟能跑完，比临场救火便宜太多。

从那以后我每次交付这类系统，都会把「删库重建 → 跑脚本 → 执行自检 → 手工走三条用例」当成固定动作，一次不落。希望帮到你。

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