SQL Server学习笔记：三层知识地图、核心语法与易错点自测

简介《SQL Server学习笔记》是一份面向数据库初学者与日常运维人员的入门型整理资料围绕SQL Server的核心概念、对象管理与基础操作展开适合课堂复习、岗前自学及知识查漏。文档系统梳理了Create、Drop、Alter等库表操作数据库对象容量限制C/S体系与编程接口以及关系模型中的实体、属性、码、域和关系等基础理论同时覆盖用户授权、系统数据库、文件组与日志文件、建库建表语句、主外键与Check、Unique等约束内容偏重概念对照和语句要点归纳。资源包共1个doc文件约499KB体积轻便便于本地检索和打印批注。已有440人学习可作为SQL Server知识框架速查与入门梳理的参考材料。1. 知识地图这份 SQL Server 学习笔记其实分三层翻开这份「SQL Server 学习笔记」第一眼是密密麻麻的数字和语法片段1MB 到 1TB、8060 个字符、1 个簇索引配 249 个非簇索引、sp_addlogin、with check option很容易被当成课堂速记。可一旦按依赖关系重排它其实是一张三层地图最底层是实例与存储包括 C/S 体系、系统数据库和 mdf/ndf/ldf 三类文件中间层是关系模型与范式涉及实体、码、域和函数依赖最上层才是天天写的语句涵盖建库建表、约束、视图、索引、存储过程和游标。三层之间是硬约束关系底层决定能放多少数据中层决定表该怎么拆上层决定语句会不会出错。这份笔记适合已经摸过 SQL、正要把零散命令串成体系的人也适合考前把术语和数字重新过一遍的人。2. 体系与存储C/S 架构、六个系统库和账号授权链这一章处理的是「数据库装在哪、谁在管、能装多少」这类问题。它们看起来最像背诵内容实际上却是后面所有语句的前提创建数据库时要指定文件和路径新建账号时要落到某个系统库判断一条语句能不能执行也要先看连接数和容量有没有超出限制。2.1 体系与对外接口C/S 架构决定了你的代码放在哪笔记开篇写的是「结构体系c/s 体系」也就是客户端/服务器结构。这一句不是背景介绍而是决定了后面所有操作的分工数据库引擎跑在服务端客户端只负责发请求和接收结果集。所以你在客户端敲的select、update本质都是把一条语句发给服务端执行再把结果拿回来。围绕这个结构笔记列了一串对外接口ODBC、VB、VC、Access。这一串的名字不用死记要记的是它们的共同点——都是「客户端接入通道」程序通过这些通道连上服务端。同一份数据能被不同语言、不同工具访问就是 C/S 加接口层带来的结果这也是后面「支持 Web、基于 Web 分析」和「数据仓库功能」的落地基础。另外两个容易只看名词就划过去的点一是「支持 XML 语言」意味着除了关系表还能用 XML 形式组织数据二是「支持分布式分区视图」和「分布式管理框架」说的是数据可以分散在多个服务器上再通过视图或管理框架拼成一个逻辑整体。复习时把这两条归到「扩展能力」而不是「基础语法」里位置就不会乱。2.2 六个系统库每个库都对应一个明确职责系统数据库这一块笔记列了六个库考试和面试都爱从这里出题因为名字好记但职责容易混。系统库职责记忆锚点master保存主数据登录账号、其他数据库信息、服务器所有配置信息全实例的「总账本」动它要小心model模板库新建数据库时以它为模板复制新建库的「母版」tempdb存储临时表每次连接都可能用到退出即消失msdb默认大小 12MB存放调度作业、警报、接收警报的操作员信息和「定时任务」绑在一起记pubs系统提供的样例数据库练习用northwind系统提供的样例数据库练习用记忆时抓住两条线索master、model、tempdb、msdb 是「真正干活的」pubs 和 northwind 是「给你练手的样例」。前四个里master 和 model 又常被搞混——master 记的是「已经存在的东西」model 决定的是「即将创建的东西」一个是账本一个是母版。注意master 里保存的是登录账号和服务器配置信息所以它一旦损坏影响的是整个实例而不只是某个库。复习到「哪个库不能随便动」这种题答案基本都指向它。2.3 mdf、ndf、ldf数据库在磁盘上的三种文件笔记里有一句很关键的话数据库的存储最终被映射成几个操作系统文件。这句话把逻辑对象和物理文件接了起来——你在语句里写的是「数据库名」磁盘上落地的却是文件。主要数据文件扩展名.mdf属于数据文件包含数据库的启动信息并存储数据。次要文件扩展名.ndf存放主要文件放不下的数据数据要分散到多个磁盘时用它来延伸。日志文件扩展名.ldf是保证事务机制和可恢复性的手段记录事务日志。三类文件的分工可以用一句话概括.mdf负责启动加存数据.ndf负责扩容.ldf负责记录和回滚。文件组则是把这些文件组织起来的管理单元方便分配和管理。日志文件最容易出错的地方是把它当成「备份文件」——它不是备份而是事务日志作用在恢复和事务完整性上。2.4 容量指标把数字按层级分开记这一串数字是这份笔记里最像「背诵材料」的部分也是考试最爱设置选项陷阱的地方。先看表。指标笔记记录的数值记忆锚点数据库大小1MB — 1TB单库容量区间每个数据库的表20 亿表的数量级每表列数最大 1024 列列数上限单行字符宽度最大 8060 个字符行宽不是列数索引每表 1 个簇索引、249 个非簇索引非簇索引最多 16 列1 比 249触发器每表 3 个INSERT、UPDATE、DELETE对应三种 DML 事件存储过程最多 1024 个参数、32 级嵌套参数与嵌套两层限制用户连接32767并发连接数锁定及打开对象20 亿和表数量同量级可同时打开的数据库327687笔记原值十万量级即可这里最容易出错的地方是把「8060 个字符」当成列宽上限。它约束的其实是单行定长数据的总宽度而「1024」才是列数上限。两个数字一个管「一行多宽」一个管「一张表几列」混在一起背做题时必然选错。同理249 是「非簇索引」的数量1 是「簇索引」的数量方向反了就成了笑话。最后一行「327687」带着明显的抄录痕迹这类数字不必死抠末位记住它属于「十万量级、远大于用户连接数」就够用了。2.5 登录、用户、角色授权的三连操作笔记里有一句总结得很干脆「数据库的授权是通过新建用户来实现的目的是对此用户指定其基于本登录所拥有的数据库操作权限。」这句话把三个概念串成了一条链登录能进服务器→ 用户能进某个数据库→ 角色在库里拥有什么权限。对应的三个系统存储过程-- 第一步创建登录账号指定密码、默认数据库、默认语言 sp_addlogin note_user, Pssw0rd, demo_db, 简体中文 -- 第二步把登录名映射为数据库内的用户名并指定所属角色 sp_adduser note_user, note_user, db_datareader -- 第三步新建自定义角色再用 grant / revoke 精细授权 sp_addrole role_editor, dbo grant select, insert on goods_1 to role_editor revoke insert on goods_1 from role_editor三个过程的参数逻辑是一致的第一个参数基本都是名称登录名、用户名、角色名后面的参数决定它落在哪个库、属于哪个角色。sp_addlogin的第三、四个参数是默认数据库和默认语言sp_adduser的第三个参数是用户组或角色sp_addrole的第二个参数是角色的拥有者。授权用grant回收用revoke这两个关键词和create、drop、alter、select、insert、update、delete一起构成了笔记开头那串语句清单。清单里特意标注了delete是「删除并保持原来数据的有序性」这是在强调删除行和删除表是两件事——delete动的是数据行drop动的才是对象本身。提示笔记里记的是sp_开头的系统存储过程写法后来版本已经改成CREATE LOGIN、CREATE USER这类 DDL 语句。复习时建议两种写法都认一下别只背一套遇到判断题时容易因为「没见过这种写法」而误判。3. 关系模型与范式从实体五件套到 1NF-3NF 拆表从这一章开始进入「表该怎么设计」的部分。它是整份笔记里概念密度最高的区域实体、属性、码、域、元组、分量这些词长得像含义却层层递进。把术语对齐了后面的建表和范式判断才有落脚点。3.1 概念模型五件套实体、属性、码、域、联系笔记对这几个概念的定义很朴素但每个都配了例子值得原样理解实体客观存在、可以相互区分的事物。属性实体具有的某一特性比如性别。码能唯一标识实体的属性集比如学号能唯一确定一个学生。域属性的取值范围比如性别只能取「男、女」学号是 11 位整数。联系实体内部的联系以及实体之间的联系。在这五个之上还有两个集合性概念实体型是用实体名加属性集合来描述同类实体写成「顾客编号、姓名、性别、年龄」这种形式实体集则是同型实体的集合比如全体顾客。这一对概念的区别在于「描述」和「实例」——实体型是那张表头实体集是表里的所有行。复习时最容易混的是「码」和「域」码解决「怎么唯一区分」域解决「能取哪些值」。一个管唯一性一个管取值范围方向完全不同。3.2 关系术语与二维表的对照关系模型这套术语本质是给「一张二维表」起了另一套名字。把两套词汇对上很多题就不用背了。关系术语对应到表说明关系一张表每张表代表一个关系元组表中的一行一条记录属性表中的一列一个字段分量元组中的一个属性值行与列交叉处的那个值域属性的取值范围列的取值约束主码能唯一确定一个元组的属性组可以是一列也可以是多列组合关系模式对关系的描述关系名、列名、域名、映射、依赖关系笔记里对关系模式的定义很完整「关系名、列名、属性所属的域名、属性向域的映射、数据间的相互依赖关系」。这五项其实就是建表语句要交代的全部内容——表名、列名、类型、约束、以及列之间的依赖。而「关系」本身要成立还得满足四个条件每一列的数据类型必须相同没有完全相同的行列与列之间的字段名不能重复没有组合列也就是一列里不能有子列不能把一列再拆成两列或更多列。这四条是后面第一范式的伏笔看到「没有组合列」就该想到 1NF。3.3 四种数据模型与关系模型的取舍笔记列了四种常用数据模型层次模型、关系模型、网状模型、面向对象模型。它们不是并列的四个知识点而是数据库发展过程中不同组织数据的方式。层次模型像一棵树网状模型像一张图关系模型用二维表把复杂结构压平面向对象模型则把对象概念引进来。关系模型能成为主流靠的是「表」这种结构足够简单查询用select修改用update约束用主键外键学习成本低。笔记里那张goods_1和bid_1的多表查询例子就是关系模型最典型的使用方式——用商品编号把两张表连起来一次查出商品名、类别和出价时间。数据模型往下再拆是数据结构、数据操作、数据的约束条件三部分。这个三分法很有用数据结构对应「有哪些表和列」数据操作对应「增删改查」约束条件对应「什么数据不能进去」。三者合起来才是一个完整的数据模型只答「关系模型就是二维表」是不完整的。3.4 1NF 到 BCNF判断顺序和拆表的两种手法范式这一块笔记用商品类别表讲了个很具体的错误案例一张表里放了商品编号和「所属类别 1、类别 2、类别 3」三列查「生活用品」的商品编号时结果为空。原因就在于存在组合列——三个类别挤在一行里查询条件根本对不上。拆法有两种一是把非原子属性列变成原子列可以拆成多列也可以拆成多行二是分解表把一张表拆成多张表。拆完之后再查结果就正常了既避免了冗余也满足「没有组合列」。由此引出第一范式所设计表的每一个分量必须是不可再分的数据项每一列不能是集合、序列这类非原子属性。第二范式要解决的是部分依赖。笔记里的例子是一张购买信息表用「用户编号 商品编号」做联合主键create table buy_info ( 购买了商品的用户编号 varchar(10), 用户购买商品编号 varchar(10), 用户购买商品名称 varchar(10), -- 只依赖商品编号不依赖用户编号 primary key (购买了商品的用户编号, 用户购买商品编号) )问题出在第三列商品名称只由商品编号决定跟用户编号无关这就是部分依赖。联合主键一旦出现空值插入就会异常同一商品被多次购买名称就要重复存更新时容易不一致。第二范式的要求是在满足 1NF 的前提下每个非主属性都完全依赖于码不存在部分依赖于码的非主属性。判断 2NF 要先分清三类属性候选码是能唯一标识元组的属性集主码是从候选码里选定的那一个主属性是包含在任一候选码中的属性其余的是非主属性。判断时先找候选码再看每个非主属性是不是「只依赖码的一部分」。第三范式再往上一层管的是传递依赖如果 a 决定 b、b 决定 c且 c 不属于 b、b 也推不出 a就存在传递依赖。3NF 要求关系里不存在非主属性对码的传递依赖。BCNF 是修正后的第三范式把约束进一步加强到「所有决定因素都必须是候选码」。判断顺序可以固定成三步先看有没有组合列1NF再找候选码看有没有部分依赖2NF最后看非主属性之间有没有传递依赖3NF。这个顺序不能颠倒因为后一个范式都建立在前一个已经满足的基础上。4. 对象与语句建库三段式、五类约束与视图索引存储过程这一章是整份笔记里操作性最强的部分。前面讲的体系、术语、范式最终都要落到语句上建库怎么指定文件建表怎么加约束视图能不能更新索引建在哪一列存储过程怎么带参数。4.1 Create database 的三段式结构创建数据库的语句在笔记里被拆得很清楚是三段create database demo_db -- 第一段数据库逻辑名可以是中文 on -- 第二段定义数据文件 ( name demo_db, -- 逻辑文件名 filename D:\data\demo_db.mdf, -- 物理存储路径 size 10MB, -- 初始大小 maxsize 500MB, -- 可以增长到的最大值 filegrowth 5MB -- 每次增长的增量 ) log on -- 第三段定义事务日志文件 ( name demo_db_log, filename D:\data\demo_db_log.ldf, size 5MB, maxsize 200MB, filegrowth 5MB )三段的分工是第一段给名字第二段管数据文件第三段管日志文件。数据文件和日志文件各自要交代五个参数——文件名、路径、初始大小、最大大小、增长增量。这五个参数就是「文件会怎么长」的全部答案考试里常拿「没写 maxsize 会怎样」这类问题做文章。笔记还有一句提醒很实用一般用户建库时不指定方括号里的可选项关键字大小写意义相同数据库逻辑名可以用中文。换句话说最小可用的建库语句可以短到一句create database 名称其余都交给默认值。4.2 五种列级约束与三类码建表时的约束笔记列了五种每一种解决一类问题约束关键字解决什么问题关键特性主键约束primary key唯一标识每一行值不能为空且每行唯一外键约束foreign key … references建立两张表之间的对应关系操作时要顾及关联表默认值约束default用户未指定时自动填值只对未赋值的列生效检查约束check限制输入值的范围不满足就拒绝执行唯一性约束unique强制某列的值不重复和主键的区别在空值处理把五种约束写成一张表再对照三类码就清楚了候选码是能唯一标识一行的列或列组合主码是从候选码里选定的一个主码的属性叫主属性外部码用来联系不同的两张表也就是外键的来源。create table employees ( employee_id varchar(10) primary key, -- 主键唯一且非空 first_name varchar(50) not null, email varchar(50) unique, -- 唯一约束不允许重复值 hire_date datetime, salary money, dept_id varchar(10) references department(dept_id), -- 外键引用另一张表 status varchar(10) default 在职, -- 默认值未指定时自动填 constraint ck_salary check (salary 0) -- 检查约束限制取值范围 )这段建表语句把五种约束里的五种都用上了注意最后一个用了constraint加名字的写法好处是以后可以用名字单独删除或关闭这条约束。参数上要留意两点references后面跟的是另一张表的主键列check里写的是布尔表达式不满足就整条插入被拒绝。4.3 四类完整性与三种落地手段约束之所以存在是为了保证数据完整性。笔记把完整性分成四类域的完整性输入到某一列的数据是否符合这一列的要求是对「列」做的规定。实体完整性基本表每一行要有唯一标识符是对「行」做的规定一般用主键实现。用户自定义完整性用户自己定的业务规则。参照完整性维护表之间主键和外键的对应关系。这四类里域完整性和实体完整性最容易混一个管列值合不合法一个管行能不能被唯一区分。判断时看它约束的是「一格」还是「一行」。落到实现手段上笔记给了三种约束、默认、规则。约束就是上面那五种默认解决「没填值时填什么」规则解决「填进来的值必须满足什么条件」。-- 默认对象先创建再绑定到具体列 create default df_goods_type as 生活用品 sp_bindefault df_goods_type, goods.goods_type_name -- 规则对象同样先创建再绑定 create rule rl_goods_number as number 0 sp_bindrule rl_goods_number, goods.goods_number这两个语句的结构是一样的先用create造出一个独立对象再用sp_bind系列把它绑到某张表的某一列上。参数里第一个是对象名第二个是「表名.列名」的完整写法中间用点连接。绑定的意义在于「一次定义多处复用」同一套规则可以绑到多个列上。4.4 Alter table 的五种改法表建好之后要改靠alter table。笔记把它归成五类操作每一类对应一个典型场景-- 1. 增加列 alter table employees add phone_number varchar(20) -- 2. 增加约束可以先命名方便以后单独删除 alter table employees add constraint ck_hire_date check (hire_date 2990-01-01) -- 3. 删除列 / 删除约束 alter table goods drop constraint ck_goods_number alter table goods drop column goods_number -- 4. 打开或关闭约束 alter table employees check constraint all alter table employees nocheck constraint all -- 5. 修改列的数据类型或是否允许为空 alter table goods alter column goods_amount int null这里有一条必须记住的顺序删列之前要先删掉跟这一列相关的约束否则删不掉。笔记列了一串「不能删除」的情况被复制的列、用在索引中的列、用在 check、foreign key、unique、primary key 里的列、有默认值绑定的列、绑定到规则的列。所以正确的动作是两步——先drop constraint解除依赖再drop column删列。第四类操作「打开或关闭约束」在实际场景里很有用批量导入数据时临时关掉约束能提速导完再check打开。但关掉期间的数据是没有校验的这一步要自己兜底。4.5 视图四个可选子句、定义限制与可更新性视图的定义语法是create view … as select …关键在as后面那段查询它决定了用户能通过视图看到什么。create view goods_view_1 (商品名称, 商品类别) -- 括号里可以重命名列 as select goods_name, goods_type_name from goods_1 where goods_type_name 电子产品 with check option -- 对视图做增改时必须满足 where 条件with后面可以跟四个选项每个解决一个问题with encryption对存储视图语句的文本加密。with schemabinding把视图绑定到架构上底层表结构不能随便改。with view_metadata浏览元数据时返回与基表名相对的视图名。with check option对视图做插入、修改时必须遵循视图定义里 where 子句设置的条件。定义视图的查询表达式有限制这一串限制很爱考定义视图的用户必须对派生此视图的基本表有select权限查询语句不能含into、order by、compute、compute by不能引用临时表或表变量。order by被禁的原因不难理解——视图是逻辑表不保证顺序排序留到查询视图时再写。视图能不能更新update、delete、insert也有条件查询语句的from子句至少引用一个表选择列表里没有派生列没有聚合函数也不包含top、group by、union、distinct。不满足这几条视图就是只读的。修改视图用alter view语法和创建基本一致alter view goods_view_1 as select goods_name, goods_type_name from goods_1 with check option更新视图数据和更新表几乎一样只是把表名换成视图名update goods_view_1 set 商品名称 课桌 where 商品类别 电子产品这里有个细节容易忽略能更新视图不代表能更新任意视图。如果视图的from里连了多张表一次update往往只能改其中一张基表涉及两张表时删除操作也会失败。判断能不能改先回头看那四条限制。4.6 索引簇索引一个非簇索引两百多个索引的定义笔记写得很准确索引是加速检索表中记录的一种由关键字组成的树状结构作用是提高访问速度。两类索引的区别要抓住「物理顺序」这四个字类型与物理存储顺序的关系数量限制特点簇索引clustered索引顺序与表中行的物理顺序相同每表只能有 1 个按索引值排序存储整行非簇索引nonclustered结构与数据排序完全独立每表最多 249 个先查到数据位置再去取数据非簇索引的运行原理是两步走先在索引里找到数据存储的位置再到存放数据的地方取信息。所以它比簇索引多一次定位但一张表能建很多个适合不同查询条件各建一个。建索引的时机笔记给了四条经常搜索的列、需要排序的列、主键或外键、经常出现在where里的列。这四条本质都指向同一个判断——这一列被查询用得频繁就值得建索引。-- 唯一簇索引同一商品编号只能出现一次且按编号顺序物理存储 create unique clustered index goods_index_1 on goods_1 (goods_id) -- 复合索引把两个经常一起出现在 where 里的列组合起来 create index goods_index_2 on goods_1 (goods_id, goods_type_id)参数里unique表示唯一索引、不允许出现重复的索引值clustered表示簇索引asc/desc控制升序降序。写复合索引时列的顺序有讲究把最常作为查询条件的列放前面索引才可能被用上。4.7 存储过程与游标把多条语句封成一个调用存储过程的价值笔记一句话点到「一个存储过程中包含了一系列的 SQL 语句包括查询、插入、删除或更新操作这些操作都会在调用本存储过程时同时执行。」能被触发器触发的操作是update、delete、insert三种。create procedure modify_process bid_user varchar(10), -- 出价人 bid_date datetime, -- 出价时间 bid_number int, -- 出价数量 bid_goods_id varchar(10), -- 商品编号 goods_price money -- 成交金额 as update goods set goods_number goods_number - bid_number where goods_id bid_goods_id -- 扣减库存 insert into user_history values (bid_user, goods_price * bid_number, bid_date) -- 写入历史参数以开头声明在as之前as之后是过程体可以包含多条语句。这段过程做了两件事扣库存、写历史两条语句在同一个调用里执行要么都做要么都不做。调用时用execute加过程名参数按位置顺序传。笔记还提到一个容易忽略的点存储过程里的 SQL 语句是被封装起来的所以无法对它引用的表做存在性验证——建过程时不会检查表存不存在运行时才报错。游标是另一块用来逐行处理结果集标准五步declare goods_name varchar(50), goods_number int declare shop_info cursor for select goods_name, goods_number from goods where goods_name like S% -- 模糊查询取 S 开头的商品 order by goods_name, goods_number open shop_info fetch next from shop_info into goods_name, goods_number while fetch_status 0 -- 0 表示还有数据可取 begin print goods_name : cast(goods_number as varchar(10)) fetch next from shop_info into goods_name, goods_number end close shop_info deallocate shop_info -- 释放游标别忘五步是声明、打开、取数、关闭、释放。fetch_status是判断循环是否继续的关键等于 0 表示取到了数据不等于 0 说明到底了。最后一步deallocate最容易被漏掉漏了会占用资源。5. 易漏点五个看着会、一考就错的地方复习到这一章知识点基本铺完了接下来要处理的是「以为掌握了但一做题就崩」的区域。这些点不难难在平时练习时不会碰到只有考试和实际出错时才暴露。5.1 容量数字记串8060 是行宽1024 才是列数易漏点把「最大列可以有 8060 个字符」理解成「一张表最多 8060 列」或者把 249 个非簇索引记成簇索引的数量。为什么漏这一串数字在笔记里是连续排列的中间没有语义分隔读的时候大脑会自动把它们归成一类「上限」。而 8060 和 1024 都是四位数形状上又接近最容易互相顶替。怎么补背的时候给每个数字配一个量词锚点——「一行最宽 8060 字符」「一表最多 1024 列」「一表 1 个簇索引配 249 个非簇索引」。三个句子结构不同就不容易串。做题时先问自己「这个数字限制的是行、列还是索引」定位到层级再选答案。5.2 主键、唯一约束与候选码三个都在管唯一管的方式不一样易漏点把唯一约束当成主键的别名或者认为一张表只能有一个候选码。为什么漏三者在「不允许重复值」这一点上表现一样平时写建表语句时随便挑一个也能跑通于是就不再深究差别。怎么补按三句话记——候选码是「有资格当主键的列或列组合」可以有多个主键是「从候选码里选定的那一个」一张表只能有一个且值不能为空唯一约束是「额外的唯一性要求」一张表可以有很多个。空值处理是主键和唯一约束的分界点这条原文没展开复习时单独标出来核对。5.3 视图里禁写 order by习惯性带排序建视图时直接报错易漏点在create view的查询里写order by或者在视图里引用临时表。为什么漏平时写select加order by太自然了几乎成了肌肉记忆而视图的定义限制是背过的用的时候却想不起来。怎么补把「into、order by、compute、compute by」四个词当成视图的四条禁令打包记别拆开背。排序需求放到查询视图的时候再写select * from goods_view_1 order by 商品名称。临时表和表变量也不能出现在视图定义里这条一并记。5.4 删列前忘了先删约束一步下去直接失败易漏点直接alter table goods drop column goods_number结果因为列上绑着约束或默认值而失败。为什么漏建表时加的约束时间一长就忘了而且删列这个动作看起来只跟列有关很难联想到约束。怎么补养成「先查依赖、再动手」的顺序——先drop constraint再drop column。判断一列能不能删看它有没有被索引、check、外键、唯一约束、主键、默认值、规则引用只要占一条就先解除。这条在项目里也是老问题改表结构前不查依赖出错率很高。5.5 with check option 的方向管的是写不是读易漏点以为with check option会限制查询视图时返回的行。为什么漏这个名字里带「check」直觉上像是给查询结果做校验而它实际约束的是对视图执行插入和修改时数据必须满足视图定义中的 where 条件。怎么补用一句话锁死方向——「check 管写不管读」。查询视图时该返回几行还是几行只有在往视图里insert或update时新数据如果不满足 where 条件才会被拒绝。四类完整性里的「用户自定义完整性」也是同一类思路限制的是进来的数据不是出去的数据。6. 查漏补缺一页自测清单和一套验证动作复习到最后一轮最怕的不是不会而是「以为会」。我自己的做法是把整份笔记压成一张自测清单每一行对应一个能立刻验证的动作答不上来就回去翻那一节。自测问题对应章节验证方式六个系统库各管什么2.2白纸默写职责重点区分 master 和 modelmdf、ndf、ldf 分别存什么2.3画出「逻辑库→物理文件」的映射8060 和 1024 分别限制什么2.4用「行宽 / 列数」两个词各造一句话登录、用户、角色是什么关系2.5写出sp_addlogin三连的参数顺序关系的四个成立条件是什么3.2逐条对照一张自己设计的表1NF、2NF、3NF 的判断顺序3.4拿一张联合主键的表现场拆五种约束分别解决什么问题4.2写一段包含五种约束的建表语句视图不能更新的四种情况4.5举一个反例说明为什么不能更新簇索引和非簇索引差在哪4.6说出「物理顺序」和「数量限制」两点清单之外还有一套动作用系统自带的工具反向验证自己记的对不对-- 看一张表的完整结构列、类型、约束、索引一次全出来 sp_help employees -- 看视图定义的真实文本确认 with 选项有没有生效 sp_helptext goods_view_1 -- 看存储过程的参数列表和过程体 sp_helptext modify_process第一个语句给出表结构全景第二个和第三个把视图、存储过程的定义原文打出来。参数就是一个对象名加引号即可。这套动作的价值在于你以为自己记住了with check option写在哪sp_helptext一执行原文摆在那里记错的地方立刻现形。我踩过最深的那个坑是复习时只看笔记不动手把「删列前要先删约束」背得滚瓜烂熟真到改表的时候还是一步drop column下去报错才发现依赖没清。从那以后我每次动表结构都强制走一遍「先sp_help看依赖、再drop constraint、最后drop column」的三步宁可多敲一行也不给自己留后悔药。复习这件事也一样清单上的每一行都要落到一个能执行的动作上看着会不算会跑通了才算。希望帮到你。本文还有配套的精品资源点击获取