2026年5月这次软考系统架构师的考场出来我在考生群里看到好几个人问“数据库到底要怎么复习”说实话我特别理解。我第一次做真题套卷的时候上午综合知识里数据库相关的题错了六道其中有两道题甚至读了三遍题干都没反应过来考点在哪。明明平时写业务代码天天跟MySQL打交道背了几个月的索引优化和分库分表方案到头来连范式判定和优先图画法都翻车了。后来我沉下心把数据库系统部分整体过了一遍才发现问题不在知识量而在知识结构——考试要的是一套完整的理论框架不是工作中那点零散的实践经验。这篇是“数据库系统一”我先聊清楚一个问题在系统架构师考试里数据库系统到底考什么、怎么考、哪些地方容易丢分。本篇覆盖的范围包括E-R模型与关系模式转换、关系规范化的范式判定、事务与并发控制、分布式数据库与数据分片最后是我自己试验下来的备考路线。如果你是软考系统架构师或软件设计师的备考者想用最少的时间把这些核心考点吃透这篇应该对你有用。1. 数据库系统在架构师考试里的实际分量从一道失分题说起先说个数据。上午的综合知识一共75道选择题数据库方向的题一般能稳定占到10到15道占比接近两成。别小看这个比例案例分析题里每年几乎都能看到数据库设计、ER图转关系模式、事务并发分析的影子论文科目里“论信息系统架构”“论软件架构风格”这类题目也都能用上数据库层面的设计素材。换句话说数据库不是一门可以靠“临时抱佛脚”糊弄过去的副科它是贯穿三科考试的隐性主科。1.1 三个科目里数据库分别怎么考从真题分布来看综合知识里的数据库题大体分成三类我整理了一个对照关系题型常见考点考察方式概念型三级模式结构、数据独立性、ER图要素、关系模型直接考定义或判断正误计算型候选键求解、范式判定、并发调度可串行化、死锁给关系模式或调度序列手算设计型分布式数据库透明性、分库分表、2PC、备份恢复给场景描述选方案或排错下午的案例分析题数据库设计基本是“半固定节目”。常见套路是给一段业务需求描述让你补全ER图、画出关系模式、判断范式等级再问你某张表需不需要拆、怎么拆。论文科目虽然不会直接要求写数据库但你只要做过项目数据库设计一定能成为论文里的支撑素材尤其写到高可用、性能优化、系统演进时数据库方案的铺垫比泛泛讲流程有用得多。1.2 容易被忽略的“隐性考点”我踩过最大的坑是时间分配。数据库看着不难但计算题一旦卡住十分钟就搭进去了。综合知识一道题平均只有一分钟多一点如果你在范式判定上磨太久后面操作系统、嵌入式、网络那些送分题反而来不及看。所以我的建议是数据库部分必须练到“看到关系模式就能条件反射式地走流程”不能到了考场上才慢慢推导。2026年5月这次真题考完群里不少人在讨论一道建模题大概是“某餐饮系统需要记录顾客、员工、菜品、订单和餐台的信息”。这种题看起来朴素真正做起来好几处容易漏订单和菜品之间的“订单明细”要不要单独建表一个订单能不能对应多个餐台员工和订单是一对多还是多对多这些判断就是ER模型专题要解决的核心问题。2. E-R模型专题从实体联系图到关系模式的转换规则E-R模型是数据库系统考试的入口级考点也是我最开始掉以轻心的地方。总觉得画图谁不会实体一个框、联系一个菱形考试还能考出花来后来一刷真题才发现转换规则才是真正拉开差距的地方——画的图再漂亮转成关系模式时漏了外键或丢失了联系属性分照样扣。2.1 实体、属性、联系的约定与判型方法先明确基本约定矩形表示实体椭圆形表示属性菱形表示联系线段连接属性和实体或联系。这里有两个容易混淆的点。第一个是主键与部分键。普通实体的标识属性直接作为主键但弱实体没有独立主键。比如“员工家庭成员”这个实体必须要用“员工号家庭成员序号”联合做主键因为家庭成员这个实体离开员工就没有独立存在意义。考试里如果出现弱实体转换时一定要记住把“依赖实体的主键”融进去当外键和联合主键的一部分。第二个是多值属性和派生属性。一个实体有多个值比如员工的多个联系电话就应该拆成一张独立的属性表用外键关联回来。派生属性比如“年龄”可以由“生日”算出通常不单独建表除非题目明确要求冗余存储。2.2 联系类型与转表规则的对应表联系类型决定了关系模式怎么生成这里我直接给一个自查表做题时对着看联系类型转换策略说明1:1建议并入任意一端加对方主键作外键也可以独立成表但考试一般以“并入”为最优1:N并入N端加“1”端主键作外键常见错误是独立成表多此一举M:N必须独立成表表内放两端外键和联系自身属性主键通常是两端外键的组合多元联系必须独立成表表内放各端外键和联系属性三元及以上的联系只能这样处理自联系是个特例考试里很爱考。最简单也最经典的是“员工-领导”员工表EMP(EID, ENAME, MGR)其中MGR字段引用的是同一张表的EID。转换的时候员工表自己加一个外键字段指向自己的主键这样不仅保留了上下级关系还能通过自连接查询还原树形结构。如果自联系本身是M:N比如“课程先修课程”那就必须再建一张关系表存放“课程号先修课程号”。2.3 一个完整的建模示范餐厅订单系统我用2026年考生群里讨论过的那类餐饮场景做个完整示范。业务背景是顾客下单员工处理订单一个订单包含多种菜品每道菜要有数量、单价和折扣信息订单还需要记录在某个餐台消费。分析步骤分成两步走。第一步先定实体和主键顾客(Customer)、员工(Staff)、菜品(Dish)、订单(Order)、订单明细(OrderItem)、餐台(OrderTable)。第二步定联系类型顾客与订单是1:N员工与订单是1:N订单与菜品之间因为存在“明细”实际是M:N通过OrderItem做桥梁订单与餐台是N:1。按规则转换出来的关系模式如下Customer(CID, CName, Phone)Staff(SID, SName, Role)Dish(DID, DName, Price)OrderTable(TID, Capacity, Location)OrderInfo(OID, CID, SID, TID, OrderTime, TotalAmount)OrderItem(OID, DID, Quantity, UnitPrice, Discount)这里面有个必须注意的细节OrderItem不能和OrderInfo合在一张表里。原因很简单OrderItem的记录数等于订单中的菜品行数而OrderInfo是一条订单一个记录强行合并会产生大量冗余也会让订单明细无法独立统计。这跟“订单-商品”为什么要拆分是同一个原理。我建议备考时把这种典型场景做一遍手写转换考场上遇到类似题就能直接套模板。3. 范式判定与候选键求解把属性闭包这套流程练熟范式判定是我错得最多的板块。一开始我靠死记硬背“第二范式消除部分依赖第三范式消除传递依赖”一做题就翻车因为很多题要你先求候选键才能判断主属性不会求候选键后面全卡壳。后来我把流程固定成一套机械步骤准确率才上来。3.1 函数依赖与候选键手工求闭包的完整步骤求候选键靠的是“属性闭包”。给定关系模式R(U, F)其中U是属性全集F是函数依赖集合某个属性集合X的闭包X指的是“从X出发利用F里的依赖能推出的所有属性集合。”举个例子关系模式R(U, F)UABCDEF{A→B, BC→E, E→D, D→A}求候选键。第一步找“只在依赖左侧出现绝不在右侧出现”的属性。观察FC只在BC→E的左侧出现右侧都没有C所以C必然在每一个候选键里因为缺少C就无法推导出任何东西。第二步从包含C的集合开始试。计算(BC)初始BCBC→E加入EE→D加入DD→A加入AA→B加入B。最后得到ABCDE所以BC是候选键。第三步继续尝试其他含C的组合。(CA)A→BBC→EE→DD→A能推出BCDEA所以CA也是候选键。(CD)D→AA→BBC→EE→D能推出ABCED所以CD也是候选键。(CE)E→DD→AA→BBC→E能推出DABCE所以CE也是候选键。最终这题的候选键集合是{BC, CA, CD, CE}。这里有一个易错点候选键的个数不一定是1个考试里经常出现多个候选键的情况。求完候选键再去判断主属性就很轻松A、B、C、D、E在这里全是主属性是这道题的特殊之处。3.2 1NF到BCNF的判定标准我习惯把范式判定做成一棵决策树。先看表中的属性是不是都是不可再分的原子值不是就得归一化到1NF再看非主属性是否部分函数依赖于候选键是的话不满足2NF再看非主属性是否存在传递依赖有的话不满足3NF最后看到底每个函数依赖的左侧是否都是超键只要有一个FD左侧不是超键就不满足BCNF。实际判定时有个更快的方法先把每个FD左侧的闭包求出来看它能不能包含全部属性。如果左侧闭包含所有属性该FD的左侧就是超键只要有一个FD左侧不是超键模式就不是BCNF。这比凭感觉看“有没有部分依赖”要可靠得多。3.3 不满足BCNF但满足3NF的经典例子还是用上面那个关系模式候选键有四个A、B、C、D、E都是主属性那它属于3NF吗答案是属于因为3NF只要求“非主属性不能对候选键产生部分或传递依赖”这里压根没有非主属性。但它不属于BCNF因为BCNF要求每个FD的左侧都是超键而A→B这个依赖里A的闭包是AB并不包含全部属性A不是超键。这个例子很能说明问题一张表就算把所有属性都变成主属性也不一定能达到BCNF。考试里遇到这种“全主属性”的题千万不要条件反射直接答BCNF先老老实实把每个FD左侧的闭包算一遍。如果要分解到BCNF可以从A→B入手拆成R1(A,B)和R2(A,C,D,E)然后继续处理R2上的D→A和E→D一层一层往下拆直到所有模式满足BCNF。这个分解过程要多写几遍光看答案很容易觉得自己会了一上手就破功。4. 事务、封锁与并发调度画图题比背书题好拿分事务与并发控制这块教材上写得又长又绕可考试真正爱考的其实就是几个固定模型ACID的语义辨析、两段锁协议、死锁判定、可串行化调度判断。我复习的时候一度想靠背诵“隔离性靠锁实现、持久性靠日志实现”过关结果真题里一道画优先图的题直接把我打回原形所以这部分我建议重点练习“动手画”。4.1 事务的ACID四个性质分别会在哪里设陷阱ACID这四个字母每个都能出题但陷阱点不太一样。原子性指的是事务的操作要么全做要么全不做对应undo日志一致性指的是事务执行前后数据库约束不被破坏隔离性是并发事务互相不可见对应锁持久性是事务一旦提交结果不会丢失对应redo日志。考试特别喜欢把“redo日志用于恢复未提交事务的修改”这种话放到选项里让你判断正误。正确说法是undo日志用于撤销未提交事务的修改redo日志用于重做已提交但尚未写入磁盘的修改。这个细节很多人会记反。预写日志系统WAL也是高频词它的核心思想是先写日志再写数据保证系统崩溃后既能undo又能redo。你可以不用背原理但要能判断“日志先落盘”这个顺序错误会导致什么后果。4.2 两段锁协议与死锁的判定方法两段锁协议说的是任何事务必须先完整经过“加锁阶段”再去“解锁阶段”也就是拿到所有需要的锁之后才允许释放任何锁。它保证冲突可串行化但会有死锁风险。死锁判定考的是等待图把每个事务画成一个节点T1等待T2持有的锁就从T1画一条有向边指向T2。等待图里有环就说明死锁可能发生。我复习时做错一道题后总结了个经验考试给一张事务执行序列让你判断会不会死锁不要一行行去推“谁先谁后”直接画等待图。画完看有没有环有环就是死锁答案基本不会错。比在脑子里模拟锁队列靠谱得多。4.3 可串行化判定用优先图画出冲突关系可串行化是并发调度的核心概念判定方法叫“优先图”。构造规则是调度序列里事务T1和T2如果对同一数据项执行了冲突操作读-写、写-读、写-写且T1的操作发生在T2之前就画一条T1→T2的有向边。图里没有环这个调度就可串行化。举一个我练过的例子。两个事务T1执行Read(A)、Write(A)、Read(B)、Write(B)T2执行Read(A)、Write(A)。考虑这样一个调度序列r1(A), r2(A), w1(A), w2(A), r1(B), w1(B)。画优先图时A数据项上w1(A)和r2(A)冲突r2(A)在w1(A)之前所以有边T2→T1w1(A)和w2(A)冲突w1(A)在前所以有边T1→T2。此时T1和T2之间出现双向边成环所以这个调度不可串行化。这种题看着复杂其实只要认真数冲突操作并画图两分钟就能搞定。我在模拟题里做过十几道类似的稳定拿分比背教材里的可串行化定义有用一百倍。注意画图的顺序别弄反一定是“先发生的操作对应的事务”指向“后发生操作的事务”。5. 分布式数据库与数据分片案例题的高频出题场景系统架构师考试这几年越来越贴近实战分布式数据库这块的地位明显上升。上午综合知识里会考概念和模型判断下午案例题里则经常给一个“系统需要水平扩展、跨地域部署、数据量大”的场景让你谈分片策略、一致性取舍和分布式事务方案。这部分跟我日常工作贴合度最高反而是我复习时最轻松的一块。5.1 分布式数据库的透明性层次分布式数据库经常考的一种题是“用户感觉不到数据被分布在哪里”这就是透明性。教材里分为三层分片透明、位置透明、局部映象透明。考试里经常给一个应用题问某系统改表名或改变物理位置后应用程序是否受影响让你判断实现了哪种透明性。我的记忆方法是从高到低分片透明性最高用户连数据被分成几块都不需要知道SQL直接操作全部数据即可位置透明次之用户知道数据被分片但不需要关心片放在哪个节点局部映象透明最低用户知道数据和位置但不需要关心底层副本怎么分布。考场上如果看到“分片方式变化不影响应用”这类描述首选分片透明。5.2 CAP与BASE读题时要先判断系统类型CAP定理说的是分布式系统只能在一致性、可用性、分区容错性三者中选两个。但严格讲网络分区在分布式系统中是必然存在的所以实际只能做CP或AP的选择题。这里有一个常见误解很多人以为“三选二”意味着可以灵活选择实际上只要发生网络分区你必须在一致性和可用性之间二选一。真题里考CAP的时候通常会给一个具体场景比如“注册中心”“配置中心”“电商秒杀”。ZooKeeper这类配置协调服务更适合保证一致性Eureka这类注册中心则更强调可用性允许短暂读到过期数据。回答这类题的关键是先判断这个系统对一致性有多强要求如果交易、支付、库存这类强一致场景选CP如果商品浏览、社交动态这类可以接受稍后一致选AP。BASE模型基本可用、软状态、最终一致在很多互联网场景下就是这个取舍的落地方案。5.3 分库分表的切分策略与一致性哈希分库分表是案例题和论文里绕不开的实战话题。垂直切分是按业务域拆库比如把用户、订单、商品分到不同库水平切分是把同一张表的数据按某个键分散到多个节点比如按用户ID取模分成64个分片。考试经常问“按什么键切分是合理的”我的判断标准是这个键必须在查询条件里高频出现否则切完查询要跨多个分片性能反而更差。一致性哈希是水平扩展里一个重要的算法考点。大体思路是把服务器节点哈希后分布到一个环上例如0到2^32-1范围再把数据键哈希沿环顺时针找到最近的一个节点作为存储位置。节点增删时只有环上相邻区间内的数据需要迁移大部分数据位置不变。复习时最好能自己动手算一个小例子比如三个节点哈希值分别是1000、3000、5000那么哈希值在2000到3000之间的数据落在3000这个节点上。这个算法本身不难但今年真题解析相关的讨论里好几个人都栽在“顺时针找节点”的方向上方向搞反就得不了分。6. 我的备考路线和刷题节奏安排最后这部分是个人经验也是我觉得比知识点本身更值得分享的内容。软考系统架构师备考最容易出现的问题是“书看了很多题做不进去”尤其数据库这种理论性强的模块。我自己的调整过程分为三步。6.1 三个月三阶段的具体安排我把备考拆成三个阶段每个阶段一个月目标完全不同阶段时间核心任务配套动作基础梳理第1个月吃透核心概念建立知识框架教材笔记手动推导每个公式真题训练第2个月近五年真题做两遍分类整理错题周末整卷模拟工作日只做专项冲刺模拟第3个月全真模考控制答题节奏按考试时间上午下午连着做基础阶段最容易犯的错是“地毯式看书”。数据库系统概论这类教材非常厚如果你从第一章看到第十三章大概率看到后面就忘了前面。我的做法是直接以真题的考点清单为目录只精读E-R建模、关系规范化、并发控制、分布式数据库、备份恢复这五大模块看完一个模块就做对应章节的题再回头看书效率高很多。软件设计师阶段学过的文件管理、位示图之类属于操作系统考点不用占数据库复习时间分清边界能省不少精力。6.2 案例题答题模板下午案例分析题的数据库题我摸索出一套稳定的答题结构分享出来供参考。第一步先定性。题目问“该设计是否存在问题”不要上来就改表先写明违反了哪个原则或范式比如“订单表和订单明细表未拆分不满足第二范式产生大量数据冗余”。第二步再列方案。给出具体拆分后的关系模式注明主键、外键如果题目没明确说就把主键用下划线标注让阅卷人一眼看到关键信息。第三步补充风险。如果涉及分布式事务或并发补充一句可能出现的脏读、死锁或最终一致性方案这部分通常能拿到额外分。这个模板最大的作用是防止“会做但写不全”。案例题按点给分答题时把“定性、方案、风险”三行结论先写清楚后面的推导过程都是锦上添花。6.3 常见复习误区提醒我踩过并且明显影响分数的坑有三个。一是只看知识点不练计算题范式和候选键这类题手生就是会错光刷选择题的代价是你永远不会发现自己的推导过程哪里有漏洞。二是只做上午题不做下午案例题数据库设计题必须实际写关系模式和ER图我在模拟时才发现自己连“订单明细主键是联合主键”这种常识都要犹豫很久。三是不复盘错题我做了两遍真题后把错题按“范式、并发、分布式”三个标签归档考前一周只翻错题本提分非常明显关键是整理错题时要写出“我为什么错、正确思路是什么”而不是把正确答案抄一遍。如果你手头正在找真题资源优先看近五年的系统架构师真题注意自己对答案时别只对表要把每个错误选项为什么错也标出来。数据库这块的复习资料不必贪多一本教材加一套近五年真题配合自己的笔记和错题本已经足够覆盖大部分考点。我自己备考到后期最大的感觉是数据库系统这门课在架构师考试里的定位不是“背知识点”而是“练思维模型”。上午题考你概念理解是否准确下午题考你能不能把一个模糊的业务描述变成严谨的库表设计论文则看你能不能把数据库方案讲成有取舍、有依据的架构决策。所以复习策略上优先把E-R建模和范式判定练成条件反射再把并发调度和分布式分片理解透分数很快就能提上来。下一篇准备把索引优化、备份恢复、数据仓库和数据挖掘这些扩展内容补完正好凑成“数据库系统二”。备考路上有什么自己的踩坑经验欢迎在评论区一起聊。