Day28-03｜6.1.3 数据库管理系统：统一管理数据、事务与可靠性的核心软件

本文对应《系统架构设计师教程（第2版）》第6章“数据库设计基础知识”6.1.3“数据库管理系统”。数据库管理系统（Database Management System，DBMS）位于应用程序与数据库之间，负责定义、存储、检索、更新、保护和恢复数据。系统架构师不能把 DBMS 只看成“执行 SQL 的工具”，它实际上承担了数据抽象、并发控制、事务一致性、故障恢复、安全审计和资源管理等基础能力，是信息系统架构中的关键基础设施。

一、学习目标与考试定位

完成本节后，应能够说明 DBMS 的基本概念、主要组成和工作过程；理解数据定义、数据操纵、查询优化、存储管理、事务管理、并发控制、恢复、安全和完整性等功能；能够分析集中式、客户端/服务器、分布式和云数据库管理系统的特点；能够在案例题中定位锁等待、脏读、日志丢失、权限越界、慢查询和恢复失败等问题；能够在论文中说明如何根据业务质量属性选择、部署和治理 DBMS。

考试通常把 DBMS 与数据库三级模式、关系数据库、事务、并发控制和系统架构结合起来。题干可能描述多个用户同时修改数据、系统宕机后数据不一致、查询速度下降、应用直接修改数据文件、不同环境数据库结构不一致等问题。答题要从“数据由谁管理、操作如何受控、失败如何恢复、访问如何安全”四条线展开。

二、DBMS 的作用

在文件系统中，应用程序往往自己定义数据格式、访问路径、并发规则和恢复逻辑。DBMS 将这些共性能力集中起来，为多个应用提供统一的数据管理服务。

DBMS 的核心作用包括：提供数据定义语言和数据字典；提供数据查询和更新接口；管理物理存储与缓冲；优化访问计划；维护完整性约束；协调并发事务；记录日志并执行故障恢复；实施身份认证、授权和审计；支持备份、恢复、复制和运维监控。

这些功能共同实现了数据共享、数据独立性、数据安全性、数据完整性和高效访问。DBMS 并不能替代业务架构设计，业务仍需明确事务边界、数据所有权、幂等、补偿和生命周期；但 DBMS 为这些设计提供了可靠的底层机制。

三、DBMS 的主要组成

不同产品的内部名称有所差异，但从功能角度可以划分为以下部分：

四、数据定义与数据字典

数据定义功能用于创建、修改和删除数据库对象，如表、视图、索引、约束、存储过程和触发器。定义语句不仅确定字段类型，还表达主键、外键、非空、唯一和检查规则。良好的定义能让非法状态在靠近数据源的位置被阻止。

数据字典保存数据库对象的元数据，包括表和列的名称、类型、默认值、约束、索引、权限、统计信息和依赖关系。企业级系统还应维护业务数据字典，说明字段含义、口径、所有者、敏感等级、来源和生命周期。数据库中有一个字段名，并不代表不同团队对它的业务含义一致。

模式变更要受到配置和变更管理控制。增加可空字段通常可以向后兼容，删除字段、改变含义或缩小取值范围则可能破坏旧应用。大型系统常采用扩展—迁移—收缩的渐进式变更：先增加兼容结构，完成应用迁移和数据回填，再删除旧结构并验证回滚路径。

五、查询处理与优化

应用发出查询后，DBMS 通常要经过词法和语法分析、语义检查、查询重写、执行计划选择和执行。优化器会依据表统计信息、索引、数据分布、连接条件和代价模型选择访问路径。

同一条 SQL 在不同数据规模、统计信息或参数下可能产生不同执行计划。架构师和开发人员要关注全表扫描、低选择性索引、隐式类型转换、函数导致索引失效、深分页、笛卡尔积、过多连接和返回无关列等问题。性能优化必须基于慢查询日志、执行计划、实际基数、锁等待和资源指标，而不是凭感觉添加索引。

索引能减少查询扫描，但会增加存储和写入维护成本；索引过多会拖慢更新和构建，索引顺序还要结合过滤、排序和选择性。分区可以缩小扫描范围并改善管理，但分区键不合理会造成热点或跨分区查询。查询优化属于数据库和应用共同的架构问题。

六、存储管理

存储管理负责把逻辑记录映射到页、文件、表空间、磁盘或分布式节点，并管理缓冲、刷盘、索引和空间回收。缓冲池利用内存减少磁盘 I/O，日志和数据文件通常需要不同的写入和持久化策略。

在高并发场景中，架构师要考虑随机写与顺序写、热点页、磁盘吞吐、网络存储延迟、空间增长、压缩和归档。容量规划不能只估计业务数据，还要计入索引、日志、临时空间、备份、复制和增长余量。数据生命周期管理可以把热数据、温数据和冷数据分层，降低在线系统压力。

七、事务与 ACID

事务是一个不可再分的逻辑工作单元。经典 ACID 属性包括：

ACID 不是只由 DBMS 自动保证。应用必须正确设置事务边界、提交和回滚条件，避免把远程调用、长时间用户操作和不可控外部依赖放进数据库事务。跨服务业务通常要通过本地事务、消息、幂等、状态机、补偿或最终一致性实现，不能简单依赖一个全局事务。

事务过大可能持锁时间长、日志膨胀和回滚代价高；事务过小又可能留下中间状态。事务边界应围绕业务不变量和一致性要求设计。

八、并发控制

1. 并发异常

多个事务并发执行可能出现丢失更新、脏读、不可重复读和幻读。丢失更新是一个事务覆盖另一个事务的修改；脏读是读取未提交数据；不可重复读是同一事务两次读取同一行得到不同结果；幻读是同一条件查询得到的行集合发生变化。

2. 锁机制

锁可以按读写性质分为共享锁和排他锁，也可以按粒度分为行锁、页锁和表锁。锁粒度越小并发度通常越高，但管理开销也越大；锁粒度升级可能降低并发。事务要尽量按稳定顺序访问资源，缩短持锁时间，避免在事务中执行慢的网络操作。

3. 隔离级别

隔离级别用于在一致性和并发性能之间取舍。较低隔离级别允许更多并发但可能出现更多读异常；较高隔离级别提供更强隔离但可能带来锁等待、冲突和资源开销。不同 DBMS 的具体实现存在差异，不能只背名称，要结合业务说明：哪些读可以接受旧值，哪些写必须串行，哪些数据需要可重复读取。

4. MVCC 与死锁

多版本并发控制通过保存多个版本让读写减少互相阻塞，但会增加版本维护、清理和长事务风险。死锁通常是多个事务以不同顺序持有并等待锁，DBMS 可以检测并回滚其中一个事务。应用需要设置超时、重试和幂等，不能把死锁重试当作无条件解决方案。

九、故障恢复与备份

故障可分为事务故障、系统故障、介质故障和灾难性故障。恢复管理器通常利用预写日志、检查点、提交记录和备份完成恢复。预写日志要求相关日志先于数据页持久化，以便故障后重做已提交操作、撤销未提交操作。

备份包括全量、增量、差异、逻辑和物理等方式。备份策略要结合数据量、变化频率、恢复时间目标（RTO）和恢复点目标（RPO）设计。只“成功生成备份文件”不能证明可恢复，必须定期验证备份完整性并进行恢复演练，检查权限、依赖、密钥、网络和应用切换。

复制提高可用性和读能力，但副本延迟、复制中断、脑裂、误删传播和切换后数据一致性都要管理。灾备架构应定义故障判定、切换授权、数据校验、业务降级、回切和补偿，而不是只部署一个备用节点。

十、安全、完整性与审计

DBMS 安全包括身份认证、授权、访问控制、数据加密、脱敏、审计和安全配置。权限应按角色和最小必要原则授予，应用账号不应拥有不必要的结构修改、导出或管理员权限。生产数据访问要留痕，敏感字段应结合静态加密、传输加密、动态脱敏和密钥管理。

完整性约束分为实体完整性、参照完整性、域完整性和用户定义完整性。约束放在哪一层需要权衡：数据库约束能防止绕过应用的非法写入，应用约束能表达跨服务和复杂业务规则；关键规则不应只依赖前端校验。

审计日志要能回答谁在什么时候通过什么身份访问了什么数据、执行了什么操作以及结果如何。审计本身也要考虑容量、敏感信息泄露、不可篡改和查询性能。

十一、DBMS 的系统架构形态

集中式 DBMS 的数据和处理主要在一个中心节点，管理简单但存在容量和单点风险。客户端/服务器架构把应用与数据库服务分离，数据库集中管理数据，适合传统企业应用，但需要管理连接、网络和服务器资源。分布式 DBMS 将数据或处理分布到多个节点，扩展性和可用性更强，但一致性、事务、运维和故障处理更复杂。

云数据库把数据库能力通过服务提供，平台可以托管备份、升级、监控和弹性，但架构师仍需负责实例规格、网络、权限、成本、配额、数据合规和退出方案。无论哪种形态，都要明确权威数据源、故障边界、恢复机制和运维责任。

十二、案例分析：库存扣减出现超卖与锁等待

某零售系统在促销期间出现库存超卖。调查发现应用先查询库存，再在应用层判断数量是否足够，随后执行更新；两个请求可能同时读到相同库存。为修复问题，开发人员把整个下单流程放进一个长事务，事务中还调用支付和物流接口，结果又出现大量锁等待和死锁。

问题分析

原方案没有把库存不变量落实到原子更新或受控并发机制中，查询与更新之间存在竞争窗口。修复方案又把外部调用放进长事务，导致锁持有时间过长、失败重试复杂和资源占用增加。问题本质是事务边界、并发控制、幂等和跨服务一致性没有共同设计。

改进方案

库存扣减应在数据库内以带条件的原子操作或合适锁机制完成，并建立商品、仓库和订单维度的约束；请求使用业务幂等键，重复请求不能重复扣减。支付和物流不宜占用库存事务，可采用预占—确认—释放状态机、消息和补偿机制；对超时、重复消息和支付失败定义明确状态转换。缩短事务、统一锁顺序、设置超时和有限重试，持续监控锁等待、库存不一致、消息积压和补偿失败。上线前执行并发、故障和恢复测试。

十三、综合知识练习与详细答案

练习一

某开发人员认为数据库约束会降低性能，要求删除外键和唯一约束，全部在应用层校验。请评价。

参考答案：全部删除约束会使绕过应用的写入、并发竞争、脚本导入和多应用访问产生非法状态，数据一致性风险显著增加。应根据性能和架构边界分析约束，关键唯一性、参照关系和不可违反的不变量应尽量在数据库层保证；对跨服务、复杂流程规则由应用、消息和补偿协同实现；通过索引、批量操作和容量测试优化，而不是用取消约束替代设计。

练习二

系统每天自动生成数据库备份，但灾备演练恢复失败。说明“有备份”为什么不等于“可恢复”，并提出改进。

参考答案：备份可能不完整、损坏、缺少日志或依赖，恢复过程还需要权限、密钥、网络、应用配置和切换流程。应验证备份完整性和一致性，定期在隔离环境执行恢复和应用验收，测量 RTO、RPO；保存多个恢复点，保护备份不被误删或勒索；记录操作手册、责任人、切换和回切条件，并对失败原因进行改进。

练习三

一条查询在数据量较小时很快，数据增长后突然变慢。请从 DBMS 角度分析可能原因。

参考答案：可能是执行计划改变、统计信息过期、索引选择性下降、数据倾斜、全表扫描、连接结果膨胀、缓存命中率下降、磁盘或网络 I/O 饱和、锁等待和资源竞争。应查看慢查询日志、实际执行计划、统计信息、锁和资源指标，基于访问模式调整索引、SQL、分区、归档、缓存或读写隔离，并用代表性数据和压测验证，不能只盲目增加硬件。

十四、论文写作素材

论文可以这样描述 DBMS 设计：我根据系统的事务边界、数据规模、并发特征、可用性、恢复、安全和成本要求选择数据库管理系统，明确权威数据源和数据所有者。通过数据定义、约束、索引和数据字典保证逻辑结构清晰；通过执行计划、慢查询、分区和容量模型优化访问；将订单、库存和支付等强一致操作划分为合理事务，避免把外部调用放入长事务。

针对并发和故障，我选择合适的隔离级别和并发控制策略，设计幂等、超时、重试和补偿，监控锁等待、死锁、复制延迟和资源使用。通过预写日志、全量与增量备份、检查点和恢复演练保障 RTO 与 RPO，而不是只检查备份任务是否成功。安全方面实施最小权限、角色访问、传输与存储加密、脱敏和审计，生产变更通过配置管理和审批。

在分布式或云数据库场景中，我进一步评估分片、复制、网络分区、数据一致性、服务等级、成本、配额和供应商锁定，采用灰度、对账、故障切换和回滚验证。通过持续的性能、可靠性和安全度量，及时调整数据库架构，使 DBMS 成为可治理、可恢复和可演进的基础设施。

十五、今日复盘

DBMS 的价值是统一承担数据定义、存储、查询、优化、约束、事务、并发、恢复、安全和审计。架构师要理解 ACID 与事务边界，知道锁、隔离级别、MVCC、死锁、日志、备份和恢复之间的关系；要区分“执行成功”“备份成功”和“系统可恢复”；还要把权限、数据字典、模式演进和运维监控纳入整体设计。

记忆主线：

定义数据 → 组织存储 → 优化访问 → 控制事务并发 → 记录日志恢复 → 实施安全审计。

下一篇进入 6.1.4 数据库三级模式，学习外模式、模式、内模式及其映射和数据独立性。