SQL Server 2019入门：从建库建表到增删改查的完整实操指南

SQL Server 2019 入门系列写到现在，上一篇我们把安装和基础环境讲透了，这一篇直接进入正题：数据库的操作。很多新手装完 SQL Server 2019，打开 SSMS 看着左侧的对象资源管理器，反而不知道该点什么，或者照着教程敲了几行 SQL 报错就卡住了。这篇文章就是把“数据库操作”这件事从头到尾捋一遍，从建库、建表到增删改查，再到并发场景下容易踩的锁和死锁问题，全部用实际例子讲清楚。不管你是在做数据库课程设计，还是刚转行想入门数据库开发，都可以照着操作一遍。

1. 内容整体设计与思路拆解

1.1 从安装到操作的学习路线，为什么要单独写这一篇

SQL Server 2019 的入门学习通常分三个阶段：第一阶段是把软件装好、能连上服务；第二阶段是理解库、表、数据的关系，掌握最基本的 T-SQL 操作；第三阶段才是索引、存储过程、性能优化这类进阶内容。上一篇基本覆盖了第一阶段，这篇瞄准的就是第二阶段，也是大多数人第一次产生“我到底在操作什么”这个疑问的地方。

数据库的“操作”这个词范围其实挺大，图形界面点鼠标是一种操作，写 T-SQL 语句也是一种操作。我的建议是两条腿走路：先在 SSMS 里找到对应的功能按钮，搞清楚每个操作在界面里长什么样，然后再回到查询窗口里用 SQL 语句实现一遍。这样做的好处是，你对操作背后的逻辑会更有画面感，而不是单纯背代码。

举个最典型的例子，创建一个数据库，SSMS 里就是右键“数据库”节点，选“新建数据库”，填个名字点确定就完成了。但你用 T-SQL 写一遍 CREATE DATABASE StudentDB 之后，才会意识到原来刚才界面操作背后自动生成了这么一句代码，也才会开始关注数据库文件放在哪个目录、初始大小设置多少。这就是从“会用工具”到“理解原理”的转变。

1.2 为什么学习操作要从库和表入手，而不是直接背 SQL

我遇到过不少初学者，一上来就拿着各种 SQL 面试题狂刷，什么复杂 JOIN、子查询、窗口函数，结果连自己的查询在哪个数据库里执行都没搞清楚，最后报错“对象名无效”时一脸懵。原因很简单，你跳过了最基础的上下文：SQL Server 里的一切数据，都存放在“数据库”这个容器里，而数据库里最主要的结构就是“表”。

操作数据库，本质上是在回答四个问题：数据放在哪？数据长什么样？怎么把数据放进去？怎么把数据取出来？对应到 SQL Server 2019，就是库的创建和管理、表的创建和修改、INSERT 写入、SELECT 查询这四件事。后面所有的 UPDATE、DELETE、JOIN、索引优化，都是在这四个核心操作上叠加出来的。

所以这一篇不求全，但求把这条链路打通。我会用一个“学生选课”的小例子，把建库、建表、插入数据、查询统计整条流程完整走一遍，中间涉及到的细节和坑也都一并说了。这样你跟着做完以后，再看其他教程里那些零零散散的语法，会发现它们是长在同一棵树上的，就不容易乱了。

2. 核心细节解析与实操要点

2.1 连接实例与对象资源管理器，别一开始就迷路

操作 SQL Server 2019 的第一件事，其实是正确连上实例并看懂 SSMS 的界面。打开 SSMS 后，弹出的是“连接到服务器”窗口，服务器类型选“数据库引擎”，服务器名称如果是本机默认实例，填一个英文句点 . 或者 localhost 就能连上。如果想连本机命名实例，格式是“计算机名\实例名”，比如 DESKTOP-ABC123\SQLEXPRESS。

连接方式的选项里有 Windows 身份验证和 SQL Server 身份验证。新手在自己电脑上学习，用 Windows 身份验证最省事，因为安装时默认就把当前系统用户设成了管理员。但如果你以后要做开发，程序连接数据库时通常用的是 SQL Server 身份验证，所以建议至少在虚拟机或测试环境里把混合模式打开，否则后面学连接字符串会卡住。

连接成功以后，左侧对象资源管理器里能看到“数据库”“安全性”“服务器对象”等节点。学习阶段只需关注“数据库”节点。展开它，默认有四个系统数据库：master、model、msdb、tempdb。这四个库新手不用深究，只需要记住 master 是老大，千万别乱删，model 是模板、tempdb 是临时库。初学阶段建议右键“数据库”节点新建一个自己的业务库，所有练习都放里面，不要碰系统库。

2.2 库级操作：创建、修改、删除与分离附加，一次说明白

创建数据库的 T-SQL 基础语法很简单：

sql复制CREATE DATABASE StudentDB;

这条语句执行后，SQL Server 会在默认数据目录下生成两个文件，一个是主数据文件 StudentDB.mdf，一个是日志文件 StudentDB_log.ldf。mdf 存数据，ldf 存操作日志，这两个文件是数据库的物理载体。很多初学者不知道这一点，直接把文件拷走却没有做分离，导致数据库损坏或者无法附加，都是因为没理解这个文件机制。

如果你想自己控制文件位置和初始大小，可以写成这样：

sql复制CREATE DATABASE StudentDB
ON PRIMARY
(
    NAME = N'StudentDB',
    FILENAME = N'D:\SQLData\StudentDB.mdf',
    SIZE = 8MB,
    FILEGROWTH = 64MB
)
LOG ON
(
    NAME = N'StudentDB_log',
    FILENAME = N'D:\SQLData\StudentDB_log.ldf',
    SIZE = 8MB,
    FILEGROWTH = 64MB
);

这段代码里的 FILEGROWTH 表示当数据文件空间用完后自动增长的步长，单位可以是 MB 或 KB，百分比也可以。生产环境一般不建议频繁自动增长，因为文件扩展本身会带来一点 IO 开销，学习阶段则不必太纠结，保持默认即可。

删除数据库更简单，一条 DROP DATABASE StudentDB; 就能做到。但注意，这个操作是不可逆的，而且一旦执行，库里的所有数据都会消失，所以执行前一定要确认自己操作的是不是正确的库。一个很实用的自保习惯是，执行 DROP 前先看一眼当前上下文：

sql复制SELECT DB_NAME() AS CurrentDatabase;

如果返回的不是你想删的库，就别执行。这种小心谨慎的习惯，越早养成越好。

数据库的“分离”和“附加”也值得了解一下，它们的本质是把数据库文件从 SQL Server 实例中摘下来，让文件可以被复制或移动，之后再附加回去。SSMS 里右键数据库，选择“任务”→“分离”，就能把库分离成一个独立的 .mdf 文件。反过来，右键“数据库”节点选“附加”，指向 .mdf 文件即可。这个功能常用来迁移数据库，或者把同事发来的库文件挂到自己的环境里。

2.3 表级操作：主键、IDENTITY 与约束，把基础打牢

数据库建好以后，真正的核心是建表。表结构设计得是否合理，直接决定了后面所有 SQL 写起来是否顺手。很多新手一开始随手建一张不带主键的表，也不管数据类型，等数据多了才发现没法做关联查询，还得回头改结构，坑自己。

先说主键。一张表最好有一个主键字段，它的作用是唯一标识每一行数据，既保证数据不重复，又方便别的表引用它。在 SQL Server 2019 里，最常用的做法是用 IDENTITY 自增列做主键，比如：

sql复制USE StudentDB;
GO

CREATE TABLE dbo.Student
(
    StudentId INT IDENTITY(1,1) NOT NULL PRIMARY KEY,
    StudentNo NVARCHAR(20) NOT NULL UNIQUE,
    StudentName NVARCHAR(50) NOT NULL,
    Gender CHAR(1) NULL DEFAULT N'男',
    Birthday DATE NULL,
    Mobile NVARCHAR(20) NULL,
    CreateTime DATETIME NOT NULL DEFAULT GETDATE()
);
GO

这里的 IDENTITY(1,1) 表示从 1 开始，每次增加 1，也就是说插入数据时不需要手动指定 StudentId 的值，SQL Server 会自动生成。这个字段加了 PRIMARY KEY，就自动带上了非空和唯一约束。

有几个细节很容易被忽略。第一，为什么学号字段 StudentNo 用 NVARCHAR 而不用 VARCHAR？因为只要表里可能存中文，就应该优先考虑 NVARCHAR 或 NCHAR。SQL Server 里的 N 代表 Unicode，它能正确存储中文、日文等多字节字符，而 VARCHAR 在某些排序规则下可能会因为编码转换产生乱码。用 NVARCHAR 配合插入数据时的 N 前缀，比如 N'张三'，是中文环境下最保险的写法。

第二，为什么建议加 DEFAULT？比如 Gender 字段默认 N'男'，CreateTime 默认 GETDATE()，这样用户在插入数据时可以不写这两个字段，系统自动填值，减少了漏填导致的空值问题。初学者容易忽略默认值的作用，其实它在业务表里非常实用，比如记录创建时间的字段，如果没设默认值，每次 INSERT 都得手动写 GETDATE()，很容易忘。

建表之后难免要调整结构。常用的几招：

sql复制ALTER TABLE dbo.Student ADD Email NVARCHAR(100) NULL;
EXEC sp_rename 'dbo.Student.StudentName', 'Name', 'COLUMN';

第一句是新增一个可空的 Email 字段，第二句是把列名 StudentName 改成 Name。这种操作偶尔用一次可以，但不建议频繁改列名，因为一旦有视图、存储过程或程序代码引用了旧列名，你就要把所有关联的地方都改一遍，容易漏。

2.4 数据操作：INSERT、UPDATE、DELETE 的细节决定成败

表建好以后，最常用的就是数据操作，也就是增删改查。面试里说的“增删改查”，对应到 T-SQL 就是 INSERT、SELECT、UPDATE、DELETE 四个语句。语法本身不难，难的是写规范，尤其是 UPDATE 和 DELETE，少写一个 WHERE 可能就把整张表清空了。

先看 INSERT。最稳妥、也最推荐的写法是明确列出要插入的列名：

sql复制INSERT INTO dbo.Student (StudentNo, StudentName, Gender, Birthday, Mobile)
VALUES
(N'20240001', N'张三', N'男', '2005-03-12', N'13800000001'),
(N'20240002', N'李四', N'女', '2005-07-21', N'13800000002');

这里有两个要点。第一，VALUES 后面可以跟多组括号，一次插入多行，比逐条 INSERT 效率更高。第二，日期字符串 '2005-03-12' 在 SQL Server 里会被自动转换成 DATE 类型，建议统一用这种 YYYY-MM-DD 格式，避免不同语言区域导致解析差异。

UPDATE 语句最核心的原则就一句话：几乎永远都要带 WHERE。比如把张三的手机号改掉：

sql复制UPDATE dbo.Student
SET Mobile = N'13900000000'
WHERE StudentNo = N'20240001';

如果你忘了写 WHERE，结果就是这张表里所有人的 Mobile 都变成了同一个号码。特别是刚学的时候，我建议在更新前先写一条 SELECT 确认条件，再执行 UPDATE。也可以用事务包一层，错了还能回滚：

sql复制BEGIN TRAN;
UPDATE dbo.Student SET Mobile = N'13900000000' WHERE StudentNo = N'20240001';
SELECT * FROM dbo.Student WHERE StudentNo = N'20240001';
COMMIT;

看到一个原则：先 SELECT 确认影响范围，再用事务保护，最后提交。这套流程看起来啰嗦，但在生产环境里就是保命习惯。为什么？因为一旦在正式库上执行了一条错误 UPDATE，如果没有事务，数据就直接被覆盖了，大概率只能靠备份恢复，非常被动。

DELETE 语句和 UPDATE 类似，同样要慎用。区别在哪记住一句口诀：DELETE 删行、TRUNCATE 清表。DELETE 可以带 WHERE 只删部分数据，而且会记录日志、可以通过事务回滚；TRUNCATE TABLE 则是直接把整张表所有行一次性清空，速度很快，但不记录每一行的删除日志，也无法通过 WHERE 指定条件。初学者容易问为什么有时候 DELETE 很慢而 TRUNCATE 很快，答案就在这里：TRUNCATE 只做“释放页”级别的操作，而 DELETE 是一行一行删的。

3. 实操过程与核心环节实现

3.1 完整搭建学生选课场景，建两张业务表

基础语法看完了，光说不练假把式，这里我搭一个完整的学习场景。回到刚才的 StudentDB 数据库，我们再建一张课程表和一张选课关联表。

先看课程表：

sql复制USE StudentDB;
GO

CREATE TABLE dbo.Course
(
    CourseId INT IDENTITY(1,1) PRIMARY KEY,
    CourseNo NVARCHAR(20) NOT NULL UNIQUE,
    CourseName NVARCHAR(100) NOT NULL,
    Credit DECIMAL(3,1) NOT NULL
);
GO

再建选课关联表。为什么需要这张表？因为一个学生可以选多门课，一门课又可以被多个学生选，这种“多对多”关系在关系型数据库里不能靠加字段解决，得用一张中间表来记录学生和课程的对应关系。选课表里存的是 StudentId、CourseId 和成绩，恰好就是业务系统里最典型的关联查询场景：

sql复制CREATE TABLE dbo.StudentCourse
(
    Id INT IDENTITY(1,1) PRIMARY KEY,
    StudentId INT NOT NULL FOREIGN KEY REFERENCES dbo.Student(StudentId),
    CourseId INT NOT NULL FOREIGN KEY REFERENCES dbo.Course(CourseId),
    Score DECIMAL(5,2) NULL,
    SelectTime DATETIME NOT NULL DEFAULT GETDATE(),
    CONSTRAINT UQ_StudentCourse UNIQUE (StudentId, CourseId)
);
GO

好，这张表里出现了两个新概念：外键和唯一约束。外键的作用是确保 StudentId 在 Student 表里真实存在，不能插入一个不存在的学生选课记录。唯一约束则保证同一个学生不能重复选同一门课。这两个概念对维护数据一致性非常重要，但很多新手建表时图省事不加，等出问题后再补就麻烦了。

3.2 写入测试数据，一次插入多行并留意细节

表结构有了，接着写入测试数据。先给四个学生：

sql复制INSERT INTO dbo.Student (StudentNo, StudentName, Gender, Birthday, Mobile)
VALUES
(N'20240001', N'张三', N'男', '2005-03-12', N'13800000001'),
(N'20240002', N'李四', N'女', '2005-07-21', N'13800000002'),
(N'20240003', N'王五', N'男', '2004-11-05', N'13800000003'),
(N'20240004', N'赵六', N'女', '2005-01-30', N'13800000004');

再给三门课：

sql复制INSERT INTO dbo.Course (CourseNo, CourseName, Credit)
VALUES
(N'C001', N'数据库原理', 3.0),
(N'C002', N'Python程序设计', 2.5),
(N'C003', N'数据结构', 4.0);

最后插入选课记录。这里 Score 字段先保持 NULL，表示还没考试或成绩未录入，这样后面可以演示如何 UPDATE 回填：

sql复制INSERT INTO dbo.StudentCourse (StudentId, CourseId)
VALUES
(1, 1),
(1, 2),
(2, 1),
(3, 3),
(4, 2),
(4, 3);

这时如果执行：

sql复制SELECT * FROM dbo.StudentCourse;

会看到所选的 StudentId 和 CourseId 之外，Id 自动递增，SelectTime 自动填入当前时间，说明 IDENTITY 和 DEFAULT 都生效了。这就是字段设计阶段提前规划带来的好处，后面写业务代码时可以少操很多心。

3.3 UPDATE 回填成绩，DELETE 删除退选记录

假设考试结束了，需要给张三的数据库原理成绩打 90 分。这里的条件怎么写？最稳妥的做法是先查出这条选课记录的 Id，再按 Id 更新，避免同一学生选了多门课导致更新错行：

sql复制SELECT sc.Id, s.StudentNo, s.StudentName, c.CourseName
FROM dbo.StudentCourse sc
INNER JOIN dbo.Student s ON sc.StudentId = s.StudentId
INNER JOIN dbo.Course c ON sc.CourseId = c.CourseId
WHERE s.StudentNo = N'20240001' AND c.CourseNo = N'C001';

查到 Id=1，再执行：

sql复制UPDATE dbo.StudentCourse
SET Score = 90
WHERE Id = 1;

这种“先定位再更新”的写法在真实业务中很常见，因为你很难保证你写的 StudentId 和 CourseId 组合一定正确，用小范围的唯一键去定位，能最大化避免误更新。

再演示删除操作。假如李四退选了数据库原理课，我们需要删掉选课表里对应的记录。如果直接写成这样：

sql复制DELETE FROM dbo.StudentCourse
WHERE StudentId = 2;

问题就大了，这会把李四所有选课记录全删掉。正确写法应该把课程条件也带上，或者先定位到具体 Id：

sql复制DELETE FROM dbo.StudentCourse
WHERE StudentId = 2 AND CourseId = 1;

记住一个原则：DELETE 和 UPDATE 的 WHERE 条件要尽量精确到“唯一记录”或“明确范围”，而不是用宽泛条件去碰运气。学习阶段多敲几遍，养成肌肉记忆，以后到项目里才不会翻车。

3.4 SELECT 查询从单表到 JOIN，再到聚合统计

查数据是整个 SQL 里花样最多的部分。先来最简单的，查学生表全部数据：

sql复制SELECT StudentNo, StudentName, Gender, Birthday, Mobile
FROM dbo.Student;

接着看 JOIN。为什么需要 JOIN？因为业务数据分散在多张表里，选课记录里只存了 StudentId 和 CourseId，并不会把学生姓名和课程名冗余进来，这样设计是为了减少数据重复和更新异常。当我们需要同时显示学生姓名和课程名时，就得把三张表连起来查：

sql复制SELECT s.StudentNo,
       s.StudentName,
       c.CourseName,
       sc.Score
FROM dbo.Student s
INNER JOIN dbo.StudentCourse sc ON s.StudentId = sc.StudentId
INNER JOIN dbo.Course c ON sc.CourseId = c.CourseId
ORDER BY s.StudentNo, c.CourseName;

INNER JOIN 的意思是只返回两边都能匹配上的记录。如果你想看所有学生的选课情况，包括那些没选课的人，就要用 LEFT JOIN，以 Student 表为主表，右边匹配不到就返回 NULL。这两种 JOIN 一定要分清楚，面试和实操都爱考。

最后是聚合统计。比如统计每门课的选课人数和平均分：

sql复制SELECT c.CourseName,
       COUNT(sc.Id) AS StudentCount,
       AVG(sc.Score)  AS AvgScore
FROM dbo.Course c
LEFT JOIN dbo.StudentCourse sc ON c.CourseId = sc.CourseId
GROUP BY c.CourseName
HAVING COUNT(sc.Id) > 0
ORDER BY StudentCount DESC;

GROUP BY 在这里的角色是“按课程分组”，COUNT、AVG 则分别计算每组内的记录数和平均分。初学者容易把 WHERE 和 HAVING 搞混，简单记一下：WHERE 是在分组之前过滤行，HAVING 是在分组之后过滤组。为什么这里要用 LEFT JOIN？因为即使某门课暂时没有人选，我也希望它在结果里出现，只是 COUNT 为 0。

AVG(Score) 遇到 NULL 时会自动忽略，所以如果有人的成绩还没录入，不会把平均分拉低，这是 SQL Server 在聚合函数里的默认行为，知道这一点能避免不少困惑。

4. 常见问题与排查技巧实录

4.1 中文乱码的根源，多半是数据类型和 N 前缀没配对

学习 SQL Server 2019 时，中文乱码是出现频率最高的问题之一。多数情况下，乱码不是你操作错了，而是数据类型选得不合适，或者在插入中文字符时漏了 N 前缀。

比如你用 VARCHAR 字段存了中文，插入时不带 N 前缀，在某些代码页下可能没问题，但换一个排序规则或客户端环境就乱码了。最稳妥的解决方案是：凡是可能存中文的字符列一律用 NVARCHAR，插入中文字符串时写成 N'中文'，查询条件里也要带 N。查询方式和插入保持一致的规则，可以省掉大量排查乱码的时间。

还有一个容易忽略的点是数据库本身的排序规则。查看当前数据库的排序规则可以用：

sql复制SELECT name, collation_name
FROM sys.databases
WHERE name = 'StudentDB';

如果建库时排序规则选的是 Chinese_PRC_CI_AS，中文环境下基本没问题。CI 表示不区分大小写，AS 表示区分重音。如果你建的库已经开始出现诡异的中文排序问题，确认一下排序规则通常是第一步。

4.2 登录失败连不上实例，先按这个顺序排查

新手最容易遇到的错误之一就是 SQL Server 2019 连不上，无论是“用户 'sa' 登录失败”还是“无法连接到 DESKTOP-XXX”，这类问题的排查思路其实很固定。

第一步检查 SQL Server 服务是否启动。按下 Win+R，输入 services.msc，找到 SQL Server (MSSQLSERVER) 或 SQL Server (SQLEXPRESS)，确认状态是“正在运行”。第二步确认连接信息，服务器名称、身份验证模式、用户名和密码是否对得上。第三步，如果之前一直是 Windows 身份验证，后来在 SSMS 里开了 SQL Server 身份验证却仍然登录失败，多半是 sa 账户被禁用或密码策略太复杂，可以用 Windows 身份登录后在查询窗口执行：

sql复制ALTER LOGIN sa WITH PASSWORD = 'YourStrongPassword123';
ALTER LOGIN sa ENABLE;

这里要特别提醒一句，启用 sa 并设置强密码只适合本地测试环境，生产服务器不要轻易开 sa，或者开了以后要严格控制来源 IP。另外，改完身份验证模式后，如果连接还失败，需要重启一下 SQL Server 服务，光在 SSMS 里点保存是不够的。

还有一类情况是防火墙挡了 1433 端口。SQL Server 默认实例监听 TCP 1433 端口，Windows 防火墙如果不放行，局域网内其他机器就连不上。这种问题在虚拟机里做实验时尤其常见，你在虚拟机里装好 SQL Server，宿主机程序却连不上去，十有八九是防火墙或网络模式的问题。

4.3 查询卡住不动，可能是锁和死锁在捣乱

很多初学者第一次遇到“查询一直转圈不返回结果”时都会慌，以为数据库坏了，其实大概率是锁的问题。简单理解，SQL Server 为了保证数据一致性，会在事务修改数据期间给相关数据加锁，别人想读或想改同一批数据时就得等待。最常见的场景是：你在一个查询窗口里执行了 UPDATE 或 DELETE，但忘了提交事务，窗口一直开着，另一个窗口再去查询同一张表就被阻塞了。

排查阻塞源的方法很简单，在另一个查询窗口执行：

sql复制SELECT session_id, wait_type, blocking_session_id
FROM sys.dm_exec_requests
WHERE blocking_session_id > 0;

如果返回了记录，说明确实有会话在阻塞其他会话。把 blocking_session_id 对应的那个会话找出来，看看是不是有没提交的事务，然后决定是提交还是回滚。

死锁则是更麻烦一点的情况，可以理解成两个事务各自占了一块数据，又都在等对方释放另一块数据，结果谁也等不到谁。SQL Server 会自动检测死锁，选一个开销较小的会话作为牺牲者回滚，另一个继续执行，所以死锁发生时，你通常会看到其中一个会话报错。避免死锁的方法有很多，在入门阶段最重要的一点是：多个事务访问多张表时，尽量保持相同的访问顺序，不要你按 A→B 访问，我按 B→A 访问。还有就是事务要短，尽量别在事务里做大量查询或者等待用户输入，锁持有时间越短，死锁概率越低。

4.4 入门也要学会的备份还原操作，关键时刻能救命

操作数据库，备份和还原是绕不开的基本功。哪怕你是学生做课程设计，我也强烈建议养成勤备份的习惯，毕竟不小心删了表再重建的滋味不好受。

最简单的备份语句：

sql复制BACKUP DATABASE StudentDB
TO DISK = N'D:\SQLBackup\StudentDB_20240601.bak'
WITH INIT, COMPRESSION;

INIT 表示覆盖同名备份文件，COMPRESSION 表示启用备份压缩，能显著减小备份文件体积。备份完成后，可以在 D:\SQLBackup 目录下看到生成的文件。

还原就更关键了。SSMS 里右键“数据库”节点，选择“还原数据库”，设备里指定之前生成的 .bak 文件即可。初学者常遇到的问题不是不会点，而是还原时报错“数据库正在使用，无法获得独占访问权”。这是因为当前有别的窗口正连着这个库。解决办法有两个：一是把所有相关查询窗口都关掉；二是在还原界面左侧“选项”页勾选“关闭现有连接”，或者先强制把库设为单用户模式：

sql复制ALTER DATABASE StudentDB SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
RESTORE DATABASE StudentDB FROM DISK = N'D:\SQLBackup\StudentDB_20240601.bak' WITH REPLACE;
ALTER DATABASE StudentDB SET MULTI_USER;

这里 SET SINGLE_USER 会把其他连接踢掉，RESTORE 执行完后再改回多用户模式。一定要记住最后要改回 MULTI_USER，否则其他程序就再也连不上了。养成这个思维习惯，以后做任何有关数据库的恢复操作都会稳妥很多。

5. 延伸建议：把基础操作往“精通”方向推

5.1 从操作到理解：多关注系统库和系统视图

当你熟练了基本的增删改查，下一步不是急着学更多语法，而是要学会“问数据库要信息”。SQL Server 提供了很多系统视图，你可以把它们理解成“数据库自己记的日记”，随时可以查看库、表、索引、会话的状态。

比如查看当前实例下所有数据库：

sql复制SELECT name, database_id, create_date
FROM sys.databases;

查看某张表的字段信息：

sql复制SELECT name, system_type_id, max_length, is_nullable
FROM sys.columns
WHERE object_id = OBJECT_ID(N'dbo.Student');

这些系统视图初看有点枯燥，但它们能极大帮助你理解 SQL Server 的内部结构。当你遇到一个不懂的问题，能写一句查询去看系统表的状态，基本就脱离了“只会用界面”的阶段了。

5.2 想进实战和面试，索引和事务是下一个必学点

如果你正在准备数据库相关面试，或打算用 SQL Server 做课程设计，那除了增删改查，还有几个知识点绕不开。第一个是索引，尤其是聚集索引和非聚集索引的区别。你可以把聚集索引理解成一本书的页码，它决定了数据物理存储的顺序；非聚集索引则像书后面的关键词索引，它指向具体内容的位置。提升查询性能时，索引通常是最先考虑的方案。

第二个是事务的 ACID 特性。事务不只是 BEGIN TRAN 和 COMMIT 两句语法，更重要的是要理解原子性、一致性、隔离性和持久性。面试里经常会问“如果事务执行到一半崩溃了，数据会怎样”，答案就是靠日志和回滚机制来保证不会出现“改了一半”的状态。

第三个是视图和存储过程。视图可以看作保存好的查询，它不占额外存储空间，每次查询时动态生成结果。存储过程则是一组 T-SQL 语句的集合，可以传参数、返回结果，生产环境里很多业务逻辑都靠它封装。入门学习者可以先跑通一个简单的存储过程：

sql复制CREATE PROCEDURE usp_GetStudentCourses
    @StudentNo NVARCHAR(20)
AS
BEGIN
    SELECT s.StudentNo, s.StudentName, c.CourseName, sc.Score
    FROM dbo.Student s
    INNER JOIN dbo.StudentCourse sc ON s.StudentId = sc.StudentId
    INNER JOIN dbo.Course c ON sc.CourseId = c.CourseId
    WHERE s.StudentNo = @StudentNo;
END
GO

EXEC usp_GetStudentCourses @StudentNo = N'20240001';

5.3 给继续学习者的练习建议

SQL Server 2019 的操作学习，前期最忌讳的就是只看不练，或者只背语法不建库。我带人入门的时候通常让他们用同一个案例反复练三遍：第一遍在 SSMS 图形界面里完成所有操作，第二遍全部用 T-SQL 实现，第三遍故意写错几条语句，观察报错信息并自己推理原因。这样练过之后，你对数据库的操作才算是真正有了肌肉记忆。

如果你在准备数据库课程设计，建议自己设计一个小型业务系统，比如图书管理系统、学生选课系统、超市进销存系统，只要涉及两到三张有关联的表就算合格。关键不是功能有多复杂，而是要把建表约束、插入数据、关联查询、事务回滚、备份还原这些环节都走通。这一套流程做完，比你刷十套题都管用。

最后说一点我自己的体会：数据库操作这个方向，入门不难，但想熟练需要大量踩坑积累。别怕报错，报错信息其实是最好的老师。能看懂“对象名无效”是表名拼错了，看懂“违反了 PRIMARY KEY 约束”是插入重复主键了，看懂“死锁牺牲品”是并发冲突了，水平就已经在进步了。SQL Server 2019 这套体系很成熟，把基础操作练扎实，后面再学优化、高可用都会有底气。