简介SQL Server 学习笔记面向初入数据库管理与开发的学习者用一册速查式文档梳理关系数据库的核心概念与常用操作。内容从 Create、Drop、Alter 等对象操作展开覆盖 C/S 体系、表/列/索引/触发器/存储过程的规模限制以及实体、属性、码、域和层次/关系/网状/面向对象等数据模型同时整理数据库授权、用户与角色、Master/Model/Tempdb/Msdb 等系统库作用数据文件 .mdf、次要文件 .ndf、日志文件 .ldf 与文件组建库建表、视图创建和主键、外键、默认值、check、unique 等约束写法。资源包共 1 个 doc 文件约 499KB篇幅紧凑便于按知识点检索和考前复盘。已有 440 人学习适合数据库课程入门、SQL 语句查阅和基础概念查漏补缺。1. 从一条建库语句倒推这份 SQL Server 学习笔记的知识地图翻开这份 SQL Server 学习笔记最容易被跳过的是开头那条create database … on … log on多数人觉得它只是模板抄一遍就完事。恰恰相反这条语句站在整个体系的正中间往上是 mdf、ndf、ldf 三个文件和文件组往下是表、列、约束左边挂着登录、用户、角色这条权限链右边牵着视图、索引、存储过程和游标。一份能拿来复习的笔记本质上就是把这条语句向四个方向拆开——语句层DDL/DML/DCL、模型层实体、码、域、范式、存储层文件与系统库、对象层视图、索引、过程、游标。它适合两类人正在系统学关系数据库、需要一张能按图索骥的地图的人以及考前或面试前想快速查漏补缺、把散落知识点重新串起来的人。下面按这四层往上走最后落到一份能自测的复习清单。2. 语句分层与对象边界DDL、DML、DCL 不是三件并列的事笔记开头那串 Create、Drop、Alter、Select、Insert、Update、Delete、Grant、Revoke乍看是一个平铺的清单背下来也用不上。真正梳理一遍会发现这九个词分属三个完全不同的层次动的是三样东西骨架、血肉、钥匙。分不清层次就会出现“改了表结构视图为什么还能查”“删了一列约束为什么还挂着”这类答不上来的问题。这一章先把三条线拆开再把容量参数和体系接口这两块容易被当成背诵题的内容落到场景里。2.1 三类语句各管一段结构、数据、权限Create、drop、alter 动的是结构。它们改的是数据库里“有什么”表在不在、列叫什么类型、约束挂没挂上。这类语句一旦执行影响的是后续所有查询的解析方式所以笔记里把建库、建表、建视图、建索引、改表全部归到这一层。Select、insert、update、delete 动的是数据改的是“里面装了什么”结构不变。Grant、revoke 动的是权限改的是“谁能碰”。三层混着背最典型的后果就是把delete和drop当成一回事——前者删行后者删表一个写日志可回滚一个直接把对象抹掉。原文在 delete 后面特意加了括号“删除并保持原来数据的有序性”。这句话值得单独拎出来它说的是 delete 逐行删除、每一行都写事务日志删完之后剩下的行相对顺序不变出问题还能回滚而整表清空那种做法效率高、日志量小回退起来就麻烦了。笔记里单独标注这一句说明当时踩过坑。层次关键字作用对象写日志能否回滚常见误用DDL 结构create / drop / alter库、表、视图、索引、约束是视操作而定把 drop table 当清空数据DML 数据select / insert / update / delete表中的行是select 除外能把 delete 当整表清空DCL 权限grant / revoke用户、角色、对象权限是能以为建了用户就自动有权限一段能跑通的最小闭环把三类语句串起来看-- 1) DDL建一张最小的商品表约束能少则少够用就行 create table goods ( goods_id varchar(10) not null primary key, -- 主键唯一且非空 goods_name varchar(50) not null, -- 非空插入时必须给值 goods_type varchar(20) default 生活用品, -- 默认值约束未指定时自动填入 goods_number int check (goods_number 0) -- 检查约束库存不允许为负 ); -- 2) DML插入时列的顺序必须与表定义一致值个数也必须匹配 insert into goods (goods_id, goods_name, goods_number) values (G001, 课桌, 10); -- 3) DML带条件的更新where 漏写就是全表改这是最常见的翻车点 update goods set goods_number goods_number - 1 where goods_id G001; -- 4) DML逐行删除写日志可回滚表结构还在 delete from goods where goods_id G001; -- 5) DCL把这张表的查询权限给某个数据库用户 grant select on goods to note_reader; revoke select on goods from note_reader;参数和失败点需要说清楚。varchar(10)里的 10 是最大字节长度超长插入会直接报错而不是悄悄截断check约束的作用范围是单行跨表的一致性得靠外键。插入失败最常见的两个原因列数或顺序与表定义不匹配以及向not null列插入了 null。笔记里那句“如果创建表时列的条件设置可以为空那么插入数据时没有此项数据可以以 null 代替”反过来读就是——没设可空就别想用 null 蒙混过去。2.2 一张容量表20 亿、1024、249、32767 怎么记容量数字是这份笔记里最像“背诵题”的部分但它们的价值不在背而在于判断“这个设计是不是已经到边界了”。比如一个库能放 20 亿张表听起来很多可真正限制你的是一个表的列数上限 1024 和行宽 8060 字符——宽表设计比表数量更容易先撞墙。对象笔记记录的上限记忆抓手数据库大小1MB — 1TB下限比上限更值得记每个库的表20 亿和“锁定及打开对象 20 亿个”是同一个量级每表最大列1024 列宽表设计的硬边界行最大宽度8060 字符char/varchar 总和不能随便堆索引每表 1 个簇索引、249 个非簇索引索引键最多 16 列“一簇多非”是判断索引题的钥匙触发器每表 3 个insert / update / delete按每种 DML 操作各一个的口径记存储过程最多 1024 个参数32 级嵌套参数上限和列上限是同一个数好记用户连接32767 个和“同时打开数据库”是同一数量级锁定及打开对象20 亿个跟着表数量一起记最容易忽略的是最后一行的写法。笔记原文记的是“可同时打开数据库327687 个”多了一位数按上下文和同组数字推断应为 32767 级别的笔误。这类数字抄错在复习时特别坑因为你看第二遍时会以为自己第一次记错了。处理办法很简单凡是同组出现的数字用数量级互相校验一遍20 亿、32767、1024 这几个数反复出现对不上就是抄错了。提示这些数字按笔记原样记录不同版本文档的口径可能有出入答题或设计时以实际环境验证为准别把笔记当规范原文引用。2.3 体系与接口C/S、ODBC 与 Web/数据仓库能力笔记第 2 到第 8 条讲的是“这个数据库能干什么”不是语法是定位。C/S 体系说的是它天生分客户端和服务端两层客户端负责发请求、服务端负责执行和存储这决定了它的权限模型必须分服务器级和数据库级两套——后面讲登录和用户时这条会反复用到。编程接口那一条列了 ODBC、VB、VC、Access重点不是记住这几个名字而是理解“接口层和上层语言无关”。同一份数据用不同语言写的程序走的是同一套驱动所以换语言不用换数据。配一个数据源大概长这样; ODBC 数据源配置示例字段含义见下方说明 [SqlServerNotes] DriverSQL Server Server127.0.0.1 Databasenotes_demo Trusted_ConnectionyesDriver指定驱动名称Server是实例地址Database是连接后默认进入的库Trusted_Connectionyes表示用当前系统账号做身份验证不再单独传用户名密码。这四项配错任意一个表现都是“连不上”但原因完全不同驱动名错是找不到驱动实例地址错是网络层超时默认库不存在是登录失败。排查时按这个顺序看比乱试快得多。剩下几条能力——支持 Web、基于 Web 分析、提供数据仓库功能、支持 XML、支持分布式分区视图、分布式管理框架——对应的是不同场景Web 分析对应把查询压力放到服务端做聚合数据仓库对应大批量导入加星型模型XML 支持对应半结构化数据的存取分布式分区视图对应把一张逻辑表拆到多台服务器上。这些不用会写但要知道它们存在面试问“这个数据库适合什么场景”时能答出层次。3. 关系模型与建表实体、码、域这套词到底在说什么这一章是整份笔记里概念密度最高的部分也是最容易被当成语文题背过去的部分。实体、属性、码、域、实体型、实体集、联系六个词其实在描述同一件事的不同粒度从“一个人”到“一类人”再到“几类人之间的关系”。把这层粒度关系理清后面的主码、候选码、外码、范式才有落脚点。3.1 概念模型五件套从一个人到一类人实体是客观存在、可以相互区分的事物比如一名学生。属性是实体具有的某一特性比如性别。域是属性的取值范围比如性别只能取“男”或“女”学号是固定位数的整数。码是能唯一标识实体的属性集比如学号——给一个学号能唯一定位到一名学生。实体型是对同类实体的抽象用实体名加属性集合表示写成“学生学号、姓名、性别、年龄”。实体集是同型实体的集合全体学生就是一个实体集。联系则是实体内部属性之间、以及实体与实体之间的关系。术语一句话定义学生例子实体可区分的事物一名学生属性实体的某一特性性别、年龄域属性的取值范围性别 ∈ {男, 女}码唯一标识实体的属性集学号实体型实体名 属性集合学生学号, 姓名, 性别, 年龄实体集同型实体的集合全体学生联系实体之间的对应关系学生—选修—课程最容易混的是“码”和“主码”。码是概念层面的只要一组属性能够唯一确定一个实体就能称为码所以一个实体型可能有多个码候选码主码是从候选码里人为选定的那一个。选哪个当主码有讲究选稳定的、短的、不含业务含义的因为主码一旦被外键引用改起来就是连锁反应。3.2 关系术语对照型与值别搞反概念模型落到关系数据库术语换了一套皮指的还是那些东西。梳理下来会发现最容易答错的是“关系模式”和“关系”这两个词关系模式是“型”是对关系的描述相当于表头关系是“值”是某一时刻表里的实际数据。同一张表结构今天和明天的数据不同但关系模式不变。关系术语对应到表说明关系一张表数据与数据之间的联系元组表中的一行一条完整记录属性表中的一列字段主码唯一确定元组的属性组可以是一列也可以是多列组合域属性的取值范围与概念模型的域一致分量元组中的一个属性值某个单元格关系模式对关系的描述型不是值主码可以是一列也可以是多列组合这一点在后面的联合主键例题里会直接用到。候选码是“能唯一标识一行”的属性组可能不止一个主码是从中选定的一个主属性是包含在任一候选码中的属性不包含在任何候选码中的叫非主属性。这套区分是判断第二范式的唯一依据现在含糊后面必然出错。3.3 四种数据模型与关系成立的五个条件常用的数据模型有四种层次模型、网状模型、关系模型、面向对象模型。层次模型像一棵树一个子节点只能有一个父节点网状模型允许一个节点有多个父节点结构更灵活但导航复杂关系模型用二维表表达一切是现在最主流的面向对象模型把数据和操作封装在一起适合复杂类型。概念模型和数据模型不是一回事概念模型面向用户用来和业务方沟通数据模型面向实现包含三要素——数据结构、数据操作、数据的约束条件。关系能成立笔记里给了五个条件一条比一条容易被忽略每一列的数据类型必须相同同一列里不能一半数字一半文本没有完全相同的行否则无法区分两个元组列与列之间的字段名不能重复没有组合列即一列里不能再有子列也不能把一列拆成两列以上行列顺序无关调换两行的位置关系本身不变。第四条是后面第一范式的伏笔。原文举的例子很典型把“商品所属类别”写成goods_type_1, goods_type_2, goods_type_3三列并排按“生活用品”去查结果为空——因为数据散在三列里任何单列条件都命中不了。这不是查询写错是表设计违反了“无组合列”。3.4 五类约束与四种完整性一一对上号建表时的约束不是随便加的每一种约束对应一种完整性要求。这层映射关系理清了写建表语句时就知道每个约束在防什么。约束关键字对应的完整性防的是什么主键约束primary key实体完整性行重复、主键为空外键约束foreign key … references参照完整性引用了不存在的父行默认值约束default域完整性未指定值时留空检查约束check用户自定义完整性值不符合业务规则唯一性约束unique实体完整性弱化版列值重复但允许一个 null四种完整性分别是域的完整性管列的输入有效性是对“列”做的规定实体完整性要求每行有唯一标识符是对“行”做的规定用户自定义完整性是业务规则参照完整性维护表与表之间主键和外键的对应关系保证增删记录时不出现孤儿行。主键和唯一性约束的区别最容易考主键不允许 null一张表只能有一个唯一性约束允许 null一张表可以有多个。笔记里对主键的描述是“主键值不能为空并保证每行都有一个非空且唯一值”对唯一性的描述是“在定义了唯一性的列中输入的数值都必须不可重复”两句话里 null 的差别没写出来属于笔记的漏点复习时要自己补上。强制完整性的方式不止约束一种笔记里还列了默认对象和规则默认对象用create default定义、用sp_bindefault绑定到列上规则是另一种独立的约束机制。约束是建表时挂上去的默认对象和规则是事后绑定上去的前者跟表走后者可以复用到多列。现在多数场景用约束就够了但看到这两个词得知道它们属于同一类东西。3.5 数据类型char 和 varchar 的差别不在长度建表绕不开类型选择笔记里列的类型不多但每条都有坑。类型写法关键点定长字符char(n)n 取 1–8000实际存储长度就是 n超长部分被截掉变长字符varchar(n)存储大小为实际字符字节数不是 n整型int / bigint / smallint / tinyint按取值范围从大到小精确数值numeric(p[,s])p 是总位数s 是小数位货币money不加引号但要带合适的货币符号日期时间datetime表示一天内的时间点表类型table存一组数据作函数结果集只支持主键、唯一、空值约束char(n)的超长截断是硬伤插进去不报错读出来少一截排查时特别费劲。字符常量必须放在单引号或双引号里这一点在拼接 SQL 时更要小心。table类型只支持三种约束别把建表那套约束照搬过去。类型选错的代价往往不是报错而是隐式转换带来的性能问题和精度丢失比如金额用 float 存累加几次就对不上账。4. 存储与权限mdf、ndf、ldf 三个文件撑起的可恢复性很多人学数据库只学写 SQL直到某天库起不来才发现自己对“数据到底存在哪”一无所知。这份笔记在存储这块写得很细数据库被映射成几个操作系统文件文件分三类每类各管一段。权限那块同理登录、用户、角色三层链路不清楚授权就会变成“给了权限却不生效”的玄学问题。4.1 文件三件套与文件组主数据文件扩展名.mdf属于数据文件包含数据库的启动信息并存储数据一个数据库有且只有一个。次要数据文件扩展名.ndf存放主文件装不下的数据当数据要分散到多个磁盘时用它来延伸。日志文件扩展名.ldf记录用于恢复数据库的日志信息是事务机制和可恢复性的基础——没有它事务回滚和崩溃恢复都无从谈起。文件组则是把多个文件打包成一个管理单元方便分配和统一管理。文件类型扩展名数量作用主数据文件.mdf一个库一个启动信息 主体数据次要数据文件.ndf可多个分担数据跨磁盘延伸日志文件.ldf至少一个事务日志恢复依据一个常被忽略的细节日志文件不是“备份”它是事务进行中的顺序记录用来支持回滚和崩溃后的重做。把日志文件删了以为能省空间结果往往是库直接不可用。另一个细节是次要文件不能包含主文件装不下的“全部”数据这种说法要反过来理解——次要文件装的是主文件装不下的那部分主文件依然是入口。4.2 六个系统库的分工建完实例系统自带几个库每个都有明确职责混用会出事。系统库作用记忆点master保存主数据登录账号、其他数据库和服务器的所有配置信息动了它整个实例都可能起不来model模板库新建数据库时以它为蓝本改它就等于改了以后所有新库tempdb存储临时表每次重启清空别往里放正式数据msdb调度作业、警报、操作员信息默认约 12MB定时任务和告警都住这pubs样例数据库练手用northwind样例数据库练手用表结构比 pubs 完整model这一条最值得留意它是个模板包含了每个数据库都有的系统表。想给以后新建的库统一加个字段或配置改 model 就行反过来在 model 里乱加东西新建的每个库都会带上属于典型的一次失误影响一片。4.3 建库语句三段式create、on、log on建库语句的结构很固定三段第一段create database给逻辑名第二段on定义数据文件包括文件名、存储路径、初始大小、可增长到的最大值、增长增量第三段log on定义事务日志文件参数完全一样。-- 建库三段式逻辑名 - 数据文件 - 日志文件 create database notes_demo -- 数据库逻辑名可以写中文 on ( name notes_demo_data, -- 数据文件的逻辑名 filename /data/notes_demo.mdf, -- 物理路径必须指向已存在且可写的目录 size 10MB, -- 初始大小 maxsize 500MB, -- 增长上限不写则近似无限制 filegrowth 5MB -- 每次增长的增量 ) log on ( name notes_demo_log, filename /data/notes_demo.ldf, size 5MB, maxsize 100MB, filegrowth 5MB );size给太小会频繁自动增长每次增长都伴随文件操作性能会有抖动filegrowth用百分比不如用固定 MB因为百分比会随着文件变大而越增越猛。maxsize不设上限在小库上没事在大库上可能把磁盘吃满。失败时先看路径目录不存在、权限不足、磁盘剩余空间不够报错信息指向的都是filename这一行。笔记里还有两句实操提醒一般用户建库时不指定方括号里的可选项关键字大小写不敏感CREATE和create意义相同数据库逻辑名可以是中文。中文逻辑名能省事但跨平台或脚本化部署时容易出编码问题团队协作里一般还是建议英文加下划线。4.4 登录、用户、角色授权的三级链路这是权限这块最容易糊涂的地方。笔记写得很直接数据库的授权是通过新建用户来实现的目的是对用户指定其基于本登录所拥有的数据库操作权限。三层的关系是登录是服务器级的身份用户是数据库级的身份角色是权限的集合。-- 第一层建登录服务器级必须给登录名 sp_addlogin note_login, Passw0rd_demo, notes_demo, 简体中文; -- 第二层把登录映射为当前库的用户 sp_adduser note_login, note_user, note_role; -- 第三层建角色权限集合指定角色名和拥有者 sp_addrole note_role, dbo;三个存储过程的参数要记准sp_addlogin的第一个参数是用户自定义登录名称必填后面依次是密码、登录后默认数据库、登录后默认语言sp_adduser的第一个参数是已存在的登录名必填后面是用户名称、用户组用户自动成为该组成员sp_addrole的第一个参数是新角色名称必填第二个是角色拥有者。最容易踩的坑是只建了登录没建用户能连上服务器但一访问具体库就报权限错误。反过来删了登录而用户还在会留下一个没有对应身份的孤儿用户。授权本身用 grant 和 revoke前者给权限后者收回粒度可以到表、视图、列甚至存储过程的执行权限。4.5 改表五种用法与删列的前置依赖alter table的用法笔记里列了五类按改动对象分-- 1) 加列 alter table goods add goods_remark varchar(100) null; -- 2) 加约束约束名建议和列名区分开不然以后删起来容易混 alter table goods add constraint ck_goods_number check (goods_number 0); -- 3) 删列 / 删约束有依赖时必须先删约束再删列 alter table goods drop constraint ck_goods_number; alter table goods drop column goods_remark; -- 4) 打开或关闭约束批量导入数据前临时关掉导完再打开 alter table goods nocheck constraint all; alter table goods check constraint all; -- 5) 改列类型或可空性 alter table goods alter column goods_number int null;第三步的依赖清单是重点笔记列得很全被复制的列、用在索引中的列、被 check / foreign key / unique / primary key 引用的列、有相关联默认值的列、绑定到默认对象或规则的列都不能直接删。正确的顺序永远是先解依赖再删列。原文那个例子——要删“商品数量”列得先drop constraint再drop column——就是这个道理。第四步的nocheck要谨慎用。它只是让约束在后续操作中不生效约束定义还在导完数据必须手动check回来。忘了恢复脏数据就永久留在表里了等哪天约束重新生效一堆历史数据全都过不了校验。5. 视图、索引与范式五条最容易翻车的易错点这三块内容在笔记里篇幅不小但真正会扣分的地方不是“会不会写”而是“知不知道为什么这样写”。下面五条是我把笔记翻了两遍之后挑出来的高频错误每条按“错在哪、为什么会漏、怎么补”写。5.1 易错点一视图定义里塞了 order by 和临时表易漏点写视图时顺手带上order by或者 from 子句里引用了临时表语句直接报错。为什么漏平时写查询时order by是最自然的收尾动作肌肉记忆带着走。而视图定义里的查询表达式有明确限制不能包含 into、order by、compute、compute by 这些关键字不能引用临时表或表变量。临时表在用户退出或连接终止时就自动消失视图要是依赖它等于建了个随时会失效的对象。另外还有一条容易忘定义视图的用户必须对派生该视图的基本表或视图有 select 权限没权限连建都建不了。怎么补把四个禁用关键字和“两个不能引用”写成一句口诀——into、order by、compute、compute by不进视图临时表和表变量不进视图。排序需求挪到查询视图的那条 select 上视图只负责定义“看哪些列、哪些行”。权限问题在建视图前先用同一账号select一下基表验证。5.2 易错点二把 with check option 当成加密易漏点视图定义后面那串 with 选项encryption、schemabinding、view_metadata、check option四个混着用以为都是“加强安全”。为什么漏四个选项都长成with xxx的样子笔记里又挨着写不逐条对比就会糊成一团。实际上它们的职责完全不同with encryption是对存储视图语句的文本加密让別人看不到定义with schemabinding是把视图绑定到架构上基表结构一变视图就被锁住不许随便改with view_metadata影响的是浏览元数据时返回的视图名与基表名的对应方式with check option管的是数据修改——通过视图做插入、修改时必须满足视图定义里 where 子句设置的条件。最典型的翻车场景建了个只显示“电子产品”的视图加了with check option然后往视图里插一条“办公用品”直接被拒。这正是它的作用不是 bug。去掉这个选项插入会成功但插进去的行在视图里看不见因为不满足 where 条件——这种“插进去了却查不到”的现象比报错更难排查。怎么补按“管文本、管结构、管元数据、管数据”四个词对应四个选项一个词对一个选项别串。更新视图前先问一句这条数据满足视图的 where 条件吗5.3 易错点三更新视图时用了派生列或聚合函数易漏点视图查得出来一 update 就报“视图或函数不可更新”。为什么漏能查不等于能改。笔记里明确列了更新视图的条件from 子句至少引用一个表选择列表中没有派生列没有聚合函数也不包含 top、group by、union、distinct。这几条里派生列和聚合函数最容易中招因为写报表视图时天天用。怎么补建视图时就想清楚用途——只读报表视图随便写要更新的视图老老实实只选基表的原始列。真要改聚合结果去改基表别跟视图较劲。删除也一样delete 里的视图必须是可更新且正确引用一个基表的视图涉及两张表的删除语句会直接失败得拆成两条按顺序删。原文那个先删子表记录、再删主表记录的次序就是被这条规则逼出来的。5.4 易错点四一个表建了两个簇索引易漏点看到“索引能加速查询”就给每个常用列都建簇索引。为什么漏簇索引和非簇索引的差别不在“快慢”在物理顺序。簇索引的索引顺序与表中数据的物理存储顺序一致所以一个表只能有一个——数据不可能同时按两种顺序物理排列。非簇索引是另一套结构先通过索引找到数据位置再去取数据一个表可以有多个。笔记里的数字是一簇、249 非簇索引键最多 16 列。建索引的时机也有讲究笔记列了四条经常搜索的列、需要排序的列、主键或外键、经常出现在 where 里的列。反过来说更新频繁而查询很少的列不适合建索引因为每次写入都要维护索引结构。怎么补记住一句话——“簇索引定物理顺序一表一个非簇索引是查表目录可以多个”。建之前先问这张表最常用的范围查询是按哪列那一列才配得上簇索引。唯一性索引用unique关键字复合索引用多列写在括号里排序方向用asc或desc指定。-- 簇索引一个表只能有一个决定物理存储顺序 create unique clustered index idx_goods_id on goods (goods_id); -- 复合索引多列组合列的顺序会影响能否命中 create index idx_goods_type_id on goods (goods_type_id, goods_id);复合索引的列顺序不是随便排的。查询条件里先出现的那一列放前面否则索引可能用不上——这就是“最左前缀”的雏形笔记里没展开但复合索引那一行示例已经暗示了顺序的重要性。5.5 易错点五把第二范式和第三范式判反易漏点一看到联合主键就说违反第二范式一看到有依赖关系就说违反第三范式。为什么漏两个范式的关键词太像——第二范式讲“部分依赖”第三范式讲“传递依赖”一字之差判定的对象完全不同。第二范式的判定前提是“已满足第一范式”然后看有没有非主属性只依赖于码的一部分。原文的例子很典型用户编号加商品编号做联合主键商品名称只依赖商品编号这一个部分不依赖完整主键于是出现插入异常主键值不能为空商品还没人买就录不进去、更新困难同一商品名重复存多次。第三范式看的是非主属性对码的传递依赖a 推出 bb 推出 c且 c 不属于 b、b 推不出 a就存在传递依赖。怎么补判定按固定步骤走。第一步确认每个分量不可再分第一范式有组合列就先拆第二步找出所有候选码分清主属性和非主属性第三步看非主属性是完全依赖码还是只依赖码的一部分部分依赖就是第二范式问题第四步在满足第二范式的基础上看非主属性之间有没有互相推导的链条有就是第三范式问题。BCNF 是在第三范式基础上再收紧要求每一个决定因素都必须是候选码。拆表不是越细越好。笔记里那句“分量是否需要继续划分是与具体情况相关的”值得记住——范式是设计参考不是法律拆过头会带来大量连接查询性能反而下降。6. 复习清单把整份笔记压成一页自测表复习到最后一轮不适合再从头翻。我的做法是把每章压成三五个能一句话回答的问题答不上来的才回到对应章节补。下面这张表可以直接拿去当自测清单左边是问题右边是答不上来时该回去看的位置。自测问题一句话答案回查位置DDL、DML、DCL 各自动的是什么结构、数据、权限2.1delete 和整表清空的关键差别逐行删、写日志、可回滚其余行顺序不变2.1一个表最多几个簇索引、几个非簇索引1 个簇索引249 个非簇索引2.2行宽上限和列数上限分别是多少8060 字符、1024 列2.2码和主码的区别码是能唯一标识的属性集主码是选定的那一个3.1关系模式是型还是值型是对关系的描述3.2五类约束分别对应哪种完整性主键对实体、外键对参照、default 和 check 对域、unique 对实体3.4char 和 varchar 存储上的差别char 按 n 定长存varchar 按实际字节存3.5mdf、ndf、ldf 各是什么主数据文件、次要数据文件、日志文件4.1master 和 model 分别怕什么master 怕乱改配置model 怕改了模板影响所有新库4.2登录、用户、角色是什么关系服务器级身份、数据库级身份、权限集合4.4删列之前要处理哪些依赖索引、check、外键、唯一、主键、默认值、规则4.5视图定义里不能出现哪些关键字into、order by、compute、compute by5.1with check option 管什么管通过视图做增改时是否满足视图的 where 条件5.2什么样的视图不能更新有派生列、聚合函数、top、group by、union、distinct5.3第二范式和第三范式怎么区分部分依赖看第二传递依赖看第三5.5表格之外还有三个动作值得在考前固定做一遍一是把所有“数量上限”类数字集中抄在一张纸上用数量级互相校验防止把 32767 抄成 327687 这种笔误带进考场二是把建库、建表、建视图、建索引、建存储过程五个模板各手写一遍不查资料写完再对三是挑一个自己最不熟的点用一句话讲给别人听讲不顺就是没懂。我自己的教训是早期复习只爱看查询觉得建表、权限、文件这些“不考操作”的部分可以跳过结果第一次做综合题时视图不可更新的条件、删列的依赖顺序全答不上来白白丢了分。从那以后我每次复习这类系统性内容都强制走一遍“先画地图、再填模块、最后自测”的流程宁可前面慢一点也不留那种“看着眼熟但说不清”的模糊地带。这份笔记按这个顺序重新排过拿到手对着目录走一遍比自己从头翻教材快得多。希望帮到你。本文还有配套的精品资源点击获取