SQL Server关系数据库核心概念与工程实践-北京尧图网络

简介《SQL Server 学习笔记》是一份面向数据库初学者、在校学生及需快速梳理 SQL Server 知识框架的从业者的提纲式文档围绕关系数据库管理系统的主要特点与核心知识点展开帮助读者建立从概念模型到建库建表的整体认知。内容包括数据库对象的新增、删除与修改C/S 体系与编程接口表、列、索引、触发器、存储过程的规模限制以及 Master、Model、Tempdb、Msdb 等系统数据库的作用同时梳理实体、属性、码、域、元组、主码与外码等关系模型概念并整理主键、外键、默认值、CHECK、UNIQUE 等约束数据文件与日志文件、文件组、用户与角色授权、常用 SQL 数据类型及创建数据库和视图的语句结构。资源包共 1 个 doc 文档约 499KB篇幅紧凑适合按条目查阅和考前复习。已有 440 人学习可作为课堂笔记的补充便于快速定位知识点并对照理解。1. 一句话说清 SQL Server它到底在替你管什么打开一份 SQL Server 学习笔记最先进入视线的是 Create、Drop、Alter、Select 这一串大写单词看着像某种咒语。其实把 SQL Server 拆开看它就是一间带账本、带门卫、带管理员的仓库账本负责记下每一笔数据门卫负责拦住不合规矩的写入管理员负责分配谁能进哪扇门、能翻哪本账。它是一套关系数据库管理系统“关系”两个字的意思是数据以二维表的形式组织表和表之间靠共同的字段互相挂钩。搞懂它的价值在于只要你的程序需要长期、可靠、多人同时地存数据绕不开的就是这类系统。这份 SQL Server 学习笔记把建库、建表、约束、索引、视图、存储过程这些环节串成了一条线下面顺着这条线把每个概念为什么存在讲明白。2. 为什么数据库要先有「模型」再有表实体、属性、码与关系2.1 从「实体—属性—码」看现实世界怎么被搬进表里建表之前先画模型这件事听起来像多此一举直接开一张表把字段写上不就完了问题在于表只是最终产物而现实世界的描述方式跟表的结构并不是一一对应的。把一群学生搬进数据库第一步要做的不是写 CREATE TABLE而是先在脑子里把这群人的特征理清楚。实体是客观存在、可以相互区分的事物一个学生就是一个实体。属性是实体具有的某一特性性别、年龄、身高都是属性。域是属性的取值范围比如性别这个属性的域是男女学号这个属性的域是 11 位整数。码是能唯一标识实体的属性集学号就是学生实体的码——给一个学号只能对应一个学生。实体型是对同类实体的抽象刻画用实体名加属性集合表示写成「学生学号、姓名、性别、年龄」这种形式。实体集则是同型实体的集合全体学生就是一个实体集。这一层抽象叫概念模型它离人近、离机器远。往下走一步是数据模型数据模型要交代三件事数据结构数据长什么样、怎么组织、数据操作能对它做哪些动作、数据的约束条件什么值不允许出现。概念模型回答「现实世界有什么」数据模型回答「机器里怎么摆」。跳过前者直接写后者最常见的后果是表建到一半发现少了一个维度只能回头改结构之前录进去的数据全得重来。血泪经验往往就是这么攒下来的。2.2 关系模型为什么赢了层次、网状、面向对象与关系的差别数据模型不止一种。层次模型把数据组织成一棵树父节点下挂子节点查一个节点必须从根一路走下来网状模型更像一张图节点之间可以有多种连接面向对象模型把数据和操作打包成对象关系模型则用一张二维表来承载一切。这几种模型的差别用生活里的东西打比方就很清楚。层次模型像公司的组织架构图一个人只能属于一个上级跨部门找人得先绕回共同上级。网状模型像地铁线路图站点之间四通八达但每加一条线都要重新规划换乘。关系模型像一张 Excel 表每一列是一个字段每一行是一条记录想找什么就用条件筛不需要预先记住路径。关系模型能成为主流靠的是两件事。一是表达统一无论多复杂的业务最后都落到「表表之间的关联」这一个套路上学习和维护成本低。二是查询是声明式的你只说想要什么不说怎么去拿具体走哪条路径、用不用索引交给系统自己决定。这也是为什么同样一句查询加不加索引性能能差出几十倍——决定权不在写语句的人手上而在数据库的优化器手上。分布式分区视图、基于 Web 的分析、数据仓库这些能力也都是在这个统一模型之上长出来的。2.3 表和关系到底是不是一回事元组、属性、主码、域、分量日常说话时「表」和「关系」经常混着用严格讲两者是一一对应的一个关系就是一张表。围绕这个关系有一整套术语需要对齐。元组是表中的一行属性是表中的一列主码是表中能唯一确定一个元组的属性组域是属性的取值范围分量是元组中的一个属性值也就是某行某列交叉处的那个具体数据关系模式是对关系的描述通常写成「关系名属性1属性2……」。一个关系要成立得同时满足几条硬性条件每一列的数据类型必须相同不能有完全相同的两行列与列之间的字段名不能重复不能有组合列也就是一列里不许再嵌套子列不能把一列拆成两列或更多列。最后这条最容易被忽略很多设计事故都出在这里——把「类别1、类别2、类别3」并排塞进三个列看着整齐实际上把结构写死了一旦某个商品属于四类整张表就崩了。跟「码」相关的概念有三个必须分清楚。候选码是能唯一标识一行的属性组可以是一列也可以是多列的组合一张表可以有多个候选码。主码是从候选码里挑出来的那一个被选中的属性叫主属性没被任何候选码包含的属性叫非主属性。外部码外键是用来联系两张表的字段它在本表里不是主码在另一张表里是主码。举个具体例子商品表和拍卖记录表通过商品编号关联起来商品编号在商品表里是主码在拍卖记录表里就是外部码。理解了这三个码的分工后面讲约束和范式时就不会卡壳。3. 一个数据库在磁盘上长什么样文件、文件组与系统库3.1 主文件、次要文件、日志文件三种扩展名各管什么在图形界面里点「新建数据库」几秒钟就完成了容易让人以为数据库是一个抽象存在。实际上它老老实实落在磁盘上被映射成几个操作系统文件。搞清楚这几种文件的分工是排查「磁盘满了」「恢复不了」这类问题的前提。主要文件扩展名是 .mdf属于数据文件。它保存数据库的启动信息同时存储数据一个数据库有且只有一个主要文件。次要文件扩展名是 .ndf存放主要文件装不下的数据。当数据量大到需要摊到多块磁盘上时就靠次要文件把数据文件延伸出去。日志文件扩展名是 .ldf记录所有事务的改动。它是实现事务机制和可恢复性的关键事务日志是不可分割的数据库操作的日志记录一旦系统在中途断电靠它就能把数据推回一致状态。数据文件丢了还能从备份补日志文件坏了往往连最近几分钟做了什么都不知道这就是所谓的黑匣子。文件组则是为了方便管理文件而设的逻辑容器把若干文件归成一个单元统一分配。它不是必须的但当一个库的文件多到十几个时按用途分组会让备份和扩容清爽很多。建库语句把上面这些参数一次说全-- 建一个库显式指定主数据文件和日志文件 CREATE DATABASE shop ON ( NAME shop_data, -- 逻辑名后续语句用它引用 FILENAME D:\data\shop.mdf, -- 物理路径落到磁盘上的主文件 SIZE 10MB, -- 初始大小 MAXSIZE 1TB, -- 允许增长到的上限 FILEGROWTH 10MB -- 每次不够用就增长这么多 ) LOG ON ( NAME shop_log, FILENAME D:\data\shop.ldf, -- 日志文件务必和数据文件分盘 SIZE 5MB, FILEGROWTH 5MB );几个参数的含义值得单独说。SIZE 是初始大小不是最终大小MAXSIZE 是天花板写 1TB 意味着这个库最大能长到 1TB这也是这份笔记里记录的单库容量上限FILEGROWTH 是增长步长设得太小会导致频繁增长、产生大量磁盘碎片设得太大又可能一次吃掉整块盘。实际动手时一般用户在建库阶段不指定方括号里的可选项也能建成功关键字大小写不影响语义数据库的逻辑名用中文也没问题——这些细节都是降低入门门槛的设计。3.2 六个系统数据库各自的分工每个实例装好之后就自带几个系统库它们不是给业务用的但每个都缺不得。Master 保存主数据包括登录账号、其他数据库的信息、服务器的所有配置。它一坏整个实例起不来。Model 是一个模板新建数据库时会照它的样子复制一份所以往 Model 里加东西会影响之后所有新建的库。Tempdb 存临时表和中间结果每次重启清空。Msdb 默认大小 12MB存的是调度作业、警报以及接收警报的操作员信息定时任务出问题时先查它。剩下两个是自带的示例库用来练手和看范例结构生产环境里通常会被删掉。提示往 Model 里加表加字段是新手最容易踩的一个坑——当时看不出问题等下一次建库才发现每个新库都莫名其妙多了一张表。3.3 C/S 体系与编程接口为什么它能被那么多语言调用SQL Server 采用的是 C/S 体系也就是客户端/服务器架构。数据库服务端跑在一台机器上负责存储和计算客户端只发请求、收结果。这个结构决定了它天然适合多人共用几十上百个程序连到同一个服务端数据只有一份不会出现各存各的、对不上的局面。光有架构还不够客户端得能说得上话这就靠编程接口。它提供了丰富的接入方式ODBC 是通用的一套VB、VC、Access 这些语言和工具都有自己的连接通道。接口层的存在意味着一件事写业务代码的人不需要知道数据在磁盘第几个扇区只要会拼 SQL 语句就行。这也是为什么同一套数据库能被桌面程序、网站后台、报表工具同时使用。在这个基础之上它还支持基于 Web 的分析、数据仓库功能、XML 扩展标记语言以及分布式分区视图。这几种能力对应的场景不一样Web 分析面向的是把网页产生的行为数据汇总起来看趋势数据仓库面向的是把多个业务系统的数据抽出来统一口径做决策XML 支持解决的是半结构化数据的存取分布式分区视图解决的是单台机器扛不住时把一张逻辑上的大表拆到多台服务器上。这些能力不是每个项目都用得上但知道它们存在在选型时才不会误判这套系统的天花板。4. 约束、完整性与范式数据凭什么可信4.1 五种约束各守一道门数据库和 Excel 最大的区别之一是数据库会主动拒绝错误数据。这件事靠约束实现常见的五种各守一道门。主键约束对应基本表中的主码用来唯一标识每一行。主键值不能为空并且保证每行都有一个非空且唯一的值。外键约束在两张表之间建立对应关系使用户在一张表里做增删改时必须顾及另一张表。默认值约束是在用户没有指定时由系统自动指派的数据值或选项比如插入一条记录没写类别就自动填「生活用品」。检查约束check是用户自定义的规范输入值不满足规范时系统直接拒绝执行用来确保域的完整性。唯一性约束要求该列中输入的数值都不可重复强制执行值的唯一性。主键和唯一性约束经常被当成一回事差别在于一张表只能有一个主键但可以有多个唯一性约束而且唯一性约束的列在某些设置下允许为空。外键则是唯一一种跨表起作用的约束它管的不是本表的数据长什么样而是本表的数据和另一张表能不能对上。4.2 四类完整性域、实体、用户自定义、参考约束是手段完整性是目的。数据的完整性指的是存储在数据库中的所有数据必须保持正确状态在逻辑上保持一致和准确。它分四类。域的完整性是对列做的规定检查输入到某一列的数据是否符合这一列的要求也就是列的输入有效性通常靠默认值约束和检查约束实现。实体完整性是对行做的规定要求基本表中每一行都有一个唯一标识符能和其他行区分开一般用主键来实现。用户自定义完整性是业务层面的规则比如入职日期必须早于某个时间点。参考完整性维护表之间主键和外键的对应关系使用户在输入或删除记录时能保持两张表已经定义好的关系不被破坏。强制完整性的方式不止约束一种还有默认和规则。默认可以绑定到某一列上规则也是类似思路。这几种方式的区别在于作用范围和绑定方式实际项目里约束用得最多因为它跟着表定义走不需要额外的绑定步骤。4.3 三范式把表拆开的理由范式是对关系的不同数据依赖程度的要求听起来玄其实讲的是「一张表该不该拆」的判断标准。第一范式要求所设计表的每一个分量都是不可再分的数据项也就是每一列不能是集合、序列这类非原子属性。反例很好找一张商品表里有「商品编号、类别1、类别2、类别3」三列按类别查某个商品时结果为空因为它的类别可能填在第二列或第三列。这种设计的毛病在于存在组合列把结构写死了。改成第一范式有两条路把非原子属性列拆成多列或多行或者把一张表分解成多张表。要注意分量是否需要继续划分跟具体业务相关不是越细越好。第二范式在满足第一范式的基础上要求每个非主属性都完全依赖于码不能只依赖码的一部分。出问题的典型是联合主键用户编号和商品编号一起做主键商品名称这一列其实只跟商品编号有关跟用户编号无关这就叫部分依赖。部分依赖带来的直接后果是插入异常——主键值不能为空一旦某条记录没有对应的用户编号整行就插不进去同时同一件商品的名称会在多行里重复存储改名时要改多处。解决办法是把商品名称挪到商品表里只留商品编号在中间表。第三范式再进一步要求关系里不存在传递依赖也就是非主属性不能依赖另一个非主属性。用符号说就是若 a 决定 bb 决定 c且 c 不属于 b同时 b 不能决定 a那么 c 对 a 就是传递依赖不满足第三范式。箭头一画问题一目了然。在第三范式之上还有一个更严格的 BCNF也叫修正的第三范式它要求每一个决定因素本身都是候选码把第三范式覆盖不到的少数边角情况也堵住。学习阶段不必急着背定义先把「拆表是为了消除冗余和异常」这条主线抓住遇到具体表时再回头对号入座即可。4.4 索引与视图一个加速一个封装索引是加速检索表中记录的一种由关键字组成的树状结构建立它是为了提高数据库的访问速度。它可以通过使用唯一标识数据子集的某些列来建立也可以创建为与原表分开的单独数据库对象。按数据物理排列的影响分两类。簇索引判断依据是索引顺序与数据库物理存储顺序是否相同相同就是簇索引一个表只能有一个因为数据在磁盘上只能有一种排法。非簇索引按完全不同的结构对数据进行排序表的实际存储顺序不用跟着它走运行原理是先通过索引找到数据在表中的位置再跑到那个位置取数据。通俗地说簇索引像按拼音顺序装订好的字典正文翻到哪页就是哪个字非簇索引像书后的索引页先查到页码再翻回正文。一本书正文只能有一种装订顺序但索引页可以有好几份这就是数量限制的由来。需要建索引的地方有几个典型经常被搜索的列、需要排序的列、主键和外键列、经常出现在 where 条件里的列。参数上unique 表示唯一性索引不允许索引值相同的两行clustered 表示簇索引asc 和 desc 控制升序或降序。复合索引则是在多个列上一起建-- 在商品编号和商品类别编号两列上建复合索引 CREATE INDEX goods_index2 ON goods_1 (goods_id ASC, goods_type_id ASC); -- 两列一起作为检索入口单独查第二列时这个索引帮不上忙这里有个必须知道的边界复合索引对列的顺序敏感按AB建的索引只查 B 时用不上。这也解释了为什么「索引越多越快」是错的——索引本身占空间每次写入都要同步维护所有索引建得过多反而拖慢插入和更新。视图是另一类对象它是从一张或多张基本表里查出来的结果被保存成一个可查询的名字。视图不是新表不额外存一份数据只是把一段查询语句封装起来。建视图的语句结构大致是-- 建立视图只暴露商品名称和类别两列 CREATE VIEW goods_view_1 AS SELECT goods_name, goods_type_name FROM goods_1 WHERE goods_type_name 电子产品 WITH CHECK OPTION; -- 通过本视图写入的数据必须满足上面的 where 条件几个可选子句的用途各不相同。with check option 规定对视图进行插入、修改时必须遵循视图定义中查询语句设置的条件上例中往这个视图里插一条类别为「家具」的记录会被拒绝。with encryption 要求在存储视图语句文本时对其加密。with schemabinding 把视图绑定到架构上。还有个 view_metadata对于用它创建的视图描述结果集内视图时会返回相对于基表名的视图名。定义视图的查询表达式本身有限制定义视图的用户必须有对派生此视图的基本表做 select 的权限查询语句中不能含有 into、order by、compute、compute by 这些关键字不能引用临时表或表变量——临时表存在临时库里用户退出或连接终止时会自动消失撑不住一个视图的长期依赖。更新视图也有条件from 子句至少引用一个表选择列表中没有派生列不含聚合函数也不包含 top、group by、union 或 distinct。这些限制不是刁难而是因为视图背后没有独立的数据改了以后系统得能推算出该改哪张基表的哪一行。5. 常见误区与易混概念别把这几组词当成同义词5.1 主键、候选码、外键、主属性四个「码」不是一回事易混点四个词里都带「码」或「键」学习时容易背成一串同义词。为什么混它们在定义上层层嵌套——候选码包含主码主码的属性是主属性外键在本表不是码、在另一张表才是码绕一圈下来脑子里就糊了。怎么区分按「在几张表里起作用」来切。候选码和主码都在一张表内部候选码是「有资格当唯一标识的列组」主码是「最后被选中的那一个」主属性是「被任何候选码包含的列」非主属性反之外键是唯一跨表的它在本表里只是一个普通列作用是牵住另一张表的主码。一句话记住主码管自己外键管关系。5.2 簇索引与非簇索引一个改物理顺序一个只建目录易混点两者都能加快查询用起来感觉一样。为什么混执行一条 select加哪种索引都能变快从结果上完全看不出区别。怎么区分看它有没有改变数据在磁盘上的排列。簇索引和物理存储顺序一致一个表只能有一个非簇索引是另一套结构表的数据该在哪还在哪索引里存的是指向位置的线索一个表可以有很多个。判断该建哪种有个简单办法如果查询结果经常需要按某一列排序返回簇索引最合适如果只是偶尔按某列精确查找非簇索引就够而且不会打乱原有顺序。数量上限上每个表能有一个簇索引、二百多个非簇索引这个差距本身就说明了它们的定位。5.3 视图与表看着像写起来差很多易混点查询视图和查询表的语句长得一模一样容易以为视图是「另一张表」。为什么混视图有名字、能出现在 from 后面、能筛能排用起来没有区别。怎么区分视图不存数据它只是一段被保存的查询基表一变查视图的结果立刻跟着变表是实打实占用空间的对象。这个差别带来一连串后果视图的写入受基表约束、受 with check option 限制更新视图还有一堆前置条件不能有聚合、不能有 distinct 等而表只要满足约束就能随便写。另外视图可以用 with encryption 加密定义文本表没有这个概念。5.4 存储过程、触发器与游标三种「批处理」的边界易混点三者都能一次执行多条语句经常被笼统地归为「脚本」。为什么混它们都写在数据库端、都由 SQL 语句组成、都能封装逻辑。怎么区分存储过程是「被叫才动」一个存储过程里包含一系列 SQL 语句包括查询、插入、删除或更新这些操作在调用时一起执行最多可以带 1024 个参数、支持 32 级嵌套适合把一段固定的业务流程封装起来复用。触发器是「条件一到自己动」由 update、delete、insert 这类操作触发每个表可以有 INSERT、UPDATE、DELETE 三种它的定位是自动响应不是给人手动调用的。游标是「一行一行地动」declare、open、fetch、close、deallocate 一整套流程走下来才能逐条处理结果集。三者解决的是不同层级的问题存储过程封装动作触发器绑定事件游标处理逐行逻辑。用游标去干存储过程的活或者用触发器去写业务流程都是常见的翻车源头。5.5 delete、drop 与 alter三种「删」的对象不一样易混点都带「删」的意思初学者看到这三个词容易一律理解成「删掉」。为什么混中文里都能叫删但英文原词压根不是一回事。怎么区分delete 删的是表里的数据行表结构还在配合 where 可以只删一部分属于数据操作。drop 删的是整个对象表、索引、视图、数据库都能被 drop删完结构就没了。alter 根本不删东西它是修改对象结构或属性加列、删列、改数据类型、开关约束都用它。有个细节值得留意用 alter 删列时如果这一列被索引引用、被 check 或 foreign key 引用、带默认值绑定或规则绑定删除会直接失败得先把这些依赖一项项解掉才能动那一列。这也是为什么改表结构之前先查清楚有哪些对象依赖它比事后救火省事得多。6. 什么时候该用它、什么时候别硬上几个判断与一条血泪经验学到这儿概念大致齐了剩下最容易走偏的是「什么时候该用」。有一种很常见的误判既然关系数据库这么完整那所有数据都往里塞。实际上它擅长和不擅长的地方分得挺清楚。场景适合程度原因多人同时读写同一批业务数据适合C/S 体系加事务与锁天然处理并发需要严格的数据校验和表间关联适合主键、外键、检查约束层层把关报表汇总、跨系统数据整合适合数据仓库和 Web 分析能力就是为这类场景准备的单机小工具存几条配置不必装一整套服务端反而是负担轻量方案更合适数据之间毫无固定结构、字段天天变勉强关系模型的价值建立在结构相对稳定之上团队里没人愿意维护它慎重备份、日志、索引优化都需要有人负责判断的关键不在数据量大小而在「结构稳不稳定」和「有没有人管」。结构稳定、需要多人协作、需要保证不出错这套系统就值得上结构完全没定型今天加三个字段明天删两个硬塞进关系模型里会天天改表改到最后谁也不敢动。还有个学习阶段的判断这份笔记里记录了大量参数比如数据库大小 1MB 到 1TB、每个库可以有 20 亿个表、每表最大 1024 列、每列最大 8060 字符、每个表一个簇索引加二百多个非簇索引、一个存储过程最多 1024 个参数和 32 级嵌套、用户连接 32767 个、同时打开的数据库个数也有上限。这些数字不是拿来背的它们是「什么时候会撞墙」的参照系。真正写代码时几乎不会有人去数第 1025 列但当你发现某张表字段数快破千、或者一个存储过程嵌套了二十几层这些数字就会提醒你结构该重新设计了。我自己的教训来自一次改表。当时为了省事直接对着已有的一张商品表用 alter 删掉一列结果语句报错因为那一列上还绑着索引和一个检查约束。当时没搞清依赖关系一路试错最后是先把依赖对象逐个找出来解绑才把列删掉中间耽误了大半天。从那以后我每次动表结构之前都强制走一遍先列出这张表上所有的约束、索引、默认值和依赖它的视图确认清楚了再写 alter。这个习惯救过我很多次也让我真正理解了那些看起来啰嗦的约束定义其实是系统在替你留后悔药。这份 SQL Server 学习笔记把这些概念、参数和语句结构都收在了一起从建库建表到约束索引、从视图存储过程到范式与完整性按顺序翻一遍再回头对照手上的项目很多原本模糊的地方会自己清晰起来。希望帮到你。本文还有配套的精品资源点击获取

SQL Server关系数据库核心概念与工程实践

相关推荐

AUC与ROC曲线本质解析：从排序能力到业务权衡

飞书AI助手Clawedbot部署与配置全指南

BiM-VFI：双向运动场视频插帧技术解析与应用

更多资讯

CST仿真实现编码超表面分束器设计与优化

象棋炮碾丹砂杀法：肋道施压与子力效率实战解析

旅游大数据推荐系统架构与实现

getsockopt函数详解：网络编程中的套接字选项获取

线性回归在病毒传播预测中的应用与实践

无锁编程核心技术解析与性能优化实践

今日更新

猫狗目标检测数据集：VOC/COCO/YOLO三格式一体化实战包

HDU2017多校标程复现：算法竞赛工程化真题沙盒

Codex Sandbox 隔离环境拆解：AI Agent 的临时实验室如何运作

本周精选

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？