简答题整理

1. 数据库系统架构与模型理论

这部分主要考察对数据库基础概念的理解。

• 基础概念与系统组成：

  • 考题： 试说明数据、数据库、数据库管理系统和数据库系统的概念以及它们之间的关系；数据库系统由哪几部分组成？
  • 答题要点：
    1. 数据（Data）：描述事物的符号记录，含数字、文字、图形、图像、声音等，必须结合语义理解。
    2. 数据库（DB）：长期存放于计算机内、依据数据模型组织的可共享数据集合，冗余低、独立性高、易扩展。
    3. 数据库管理系统（DBMS）：位于用户与操作系统之间的数据管理软件，提供数据定义、组织存储、查询更新、事务与运行管理等功能。
    4. 数据库系统（DBS）：由数据库、DBMS（及开发工具）、应用程序、数据库管理员组成的整体；应用程序依赖 DBMS 操作数据库。
    5. 联系：DBS 是大集合；DBMS 管理数据库并向应用开放接口，DBA/应用据此进行查询、更新、删除等操作。

• 文件管理 vs. 数据库管理：

  • 考题： 比较用文件管理和用数据库管理数据的主要区别。
  • 核心点： 数据库系统在应用程序与数据之间引入 DBMS，大量存储管理和一致性工作由 DBMS 完成，使应用与存储方式解耦；文件系统中应用需直接处理物理结构，存储变化会影响程序，难以维护。

• 数据模型概念与层次：

  • 考题： 解释数据模型的概念，为什么要将数据模型分成两个层次？
  • 答题要点： 数据模型需真实刻画现实世界、易理解、易实现；难以用单一模型兼顾所有目标，因此数据库划分为概念层数据模型（面向业务语义）与组织层数据模型（面向实现）两大类，方便描述与落地。

• 三级模式与两级映像：

  • 考题： 数据库系统包含哪三级模式？两级映像有什么作用？数据库三级模式划分的优点是什么？
  • 答题要点：
    • 三级模式：外模式（面向特定用户的局部视图）、概念模式（全局逻辑结构）、内模式（物理存储结构）。
    • 外/概映像：维持外模式与概念模式的一致性，概念变化时可通过调整映像保持各外模式不变。
    • 概/内映像：定义概念结构与物理结构的对应，物理结构改变时通过调整映像保持概念模式不变。
    • 优点：把用户视图、逻辑结构、物理结构解耦，实现逻辑独立性（模式变更不影响应用）与物理独立性（存储变更不影响模式），减少相互干扰。

• 数据独立性（高频）：

  • 考题： 现代数据库如何实现数据独立性？为什么数据独立性越高越好？多级数据模式对独立性的影响？什么叫数据与程序的物理独立性、逻辑独立性？
  • 核心点： 必须答出 三级模式结构（外模式、概念模式、内模式）和 两级映像（外模式/模式映像、模式/内模式映像）。物理独立性指存储结构变化时通过调整模式/内模式映像保持概念模式、应用不变；逻辑独立性指概念模式改变时只需调整外/概映像即可保持外模式、应用不变。独立性越高改动越局部，利于维护与演化。

• 数据模型对比：

  • 考题： 关系模型 vs 网状/层次模型（M:N 关系的表达、本质区别）。
  • 核心点： 网状用指针/链表（导航式），关系用表/外键（声明式、集合运算）。

• 范式理论：

  • 考题： 数据库设计中，范式是越高越好吗？
  • 核心点： 不是。 高范式减少冗余和异常，但增加表数量和连接操作（Join），降低查询性能。需要在规范化和性能间权衡。

视图

• 使用视图的好处：
  • 考题： 视图能带来哪些优势？
  • 答题要点： (1) 简化复杂查询；(2) 让用户从不同角度观察同一数据；(3) 隐藏底层细节、提高安全性；(4) 提供一定的逻辑独立性。
• 视图与性能：
  • 考题： “使用视图可以加快查询速度”对吗？
  • 答题要点： 不对。DBMS 查询视图时会把视图定义与查询合并并转换为对基表的等价查询，仍需访问基础表，无法天然提速。

2. 索引与查询优化

这部分考察对数据库性能底层机制的理解。

• 索引效率分析（高频）：
  • 考题： 稠密索引一定能提高效率吗？为什么符合条件元组比重较大（>20%）时，非簇集索引反而不利？
  • 核心点： 不一定。如果表很小，或者查询结果集很大（低选择率），使用非簇集索引会导致大量 随机 I/O，不如全表扫描（顺序 I/O）快。
  • 详细概念：稠密/非稠密、簇集/非簇集
    • 稠密索引（Dense）：每个搜索码值对应一个索引项（或每条记录一个索引项）；定位快但索引更大、维护成本高。
    • 非稠密索引（Sparse）：只为部分搜索码值建立索引项（常见做法是“每个数据块一个索引项”）；要求数据按索引键有序；索引更小但需块内再查找。
    • 簇集索引（聚簇索引）：数据记录按索引键的物理顺序存放，一个表通常最多一个；范围查询效率高。
    • 非簇集索引：索引顺序与物理存储无关，可建多个；命中后需回表（记录指针/主键），结果集大时随机 I/O 多。
    • 关系：稠密/非稠密强调“索引项覆盖率”，簇集/非簇集强调“数据物理排序方式”，两者正交。
  • B-树、B+树、平衡二叉树对比
    • 结构：平衡二叉树每个节点最多 2 个孩子；B-树/B+树是多路平衡树，每个节点可有多个孩子（高扇出）。
    • 高度与 I/O：高扇出使 B-树/B+树树高更低，磁盘访问更少；平衡二叉树高度更大，更适合内存而非磁盘。
    • 数据存放：B-树内部节点和叶子都可存数据/记录指针；B+树内部节点只存键，数据仅在叶子。
    • 范围查询：B+树叶子按键有序且有链表，范围/排序/全表扫描更快；B-树范围查询需更多回溯。
    • 点查：B-树可能在内部命中；B+树必到叶子，但内部节点更瘦、扇出更大，整体 I/O 更稳定。
    • 应用：DBMS 索引更常用 B+ 树；平衡二叉树多见于内存结构（如 AVL/红黑树）。
  • 考题： 为什么主键上通常建主索引？B-树为何成为主流？
  • 例题： 计算 B+ 树秩（阶）。若物理块大小 492B、指针 6B，Sailors 记录字段 sid2B、sname4B、rating1B、age1B、master2B、删除标记1B，则：
    1. rating 聚簇索引：索引节点满足 2k*1 + (2k+1)*6 ≤ 492，叶子节点满足 2k*1 + 2*6 + 2k*6 ≤ 492，据此解出 k 范围。
    2. sid 主索引：索引节点 2k*2 + (2k+1)*6 ≤ 492，叶子节点 2k*2 + 2*6 + 2k*(6+2) ≤ 492。
• SQL 优化：
  • 考题： 为什么 WHERE 子句应尽量避免使用 OR？
  • 核心点： OR 难以利用索引（通常导致全表扫描），或者需要分别查询再做并集，开销大。
  • 考题： 为什么查询优化对关系数据库比对网状/层次数据库更重要？
  • 核心点： 关系数据库是 非过程化 的（只说做什么），执行路径由系统决定，优化器的好坏直接决定性能；而网状/层次是导航式的（指定怎么做），路径由程序员定死，优化空间小。
• 数据模型优化：
  • 考题： 数据模型的优化包含哪些方法？
  • 答题要点： (1) 列举并分析属性间函数依赖；(2) 极小化依赖、剔除冗余；(3) 判断每个关系模式所处范式并选择合适层级；(4) 结合需求评估分解或合并，必要时反规范化满足性能。

3. 事务并发控制（难点）

这部分主要考察锁机制和调度正确性，特别是 U 锁 的引入。

• 锁协议与死锁：

  • 考题： (S, X) 锁有什么问题？(S, U, X) 锁如何提高并发/效率？
  • 核心点： (S, X) 容易产生 升级死锁（两个事务都读 S，都想升 X，互相等待）。(S, U, X) 引入 U 锁（更新锁），允许读但不兼容 U，强制更新意图序列化，避免升级死锁。
  • 考题： 锁能完全解决死锁吗？
  • 核心点： 不能。只能避免升级死锁，无法解决多资源循环等待的死锁。
  • 考题： 解释两段锁协议（2PL）。
  • 答题要点： 事务加锁/解锁分两个阶段：扩展阶段只加锁不释放，收缩阶段释放锁但不再申请。遵循 2PL 可确保调度可串行化，是严格锁调度的基础。

• 调度正确性判断：

  • 考题： 给定一个并发调度（T1, T2 操作序列），计算最终结果，判断调度是否正确。
  • 核心点： 计算结果是否与 串行执行（T1→T2 或 T2→T1）的结果一致。如果不一致（不可串行化），则调度不正确。

• 并发控制必要性：

  • 考题： 为什么数据库必须有并发控制机制？
  • 答题要点： 多用户共享同一数据，若无同步会导致丢失更新、脏读等一致性破坏；通过锁/时间戳等并发控制保障事务隔离与数据正确。

4. 故障恢复（Recovery）

这部分考题非常固定，几乎每年必考 介质失效。

• 日志与写前原则：

  • 考题： 登记日志时为什么必须先写日志、后写数据库？
  • 答题要点： 若先写数据库、日志缺失，则崩溃后无法恢复；先写日志即使数据库未写成功也可通过 UNDO 撤销，保证 WAL（Write-Ahead Logging）安全。

• 事务 ACID 性质：

  • 考题： 事务的四个性质由哪个子系统保证？有何意义？
  • 答题要点： 原子性（事务管理器，确保全部或全不执行）；一致性（完整性子系统，保持数据约束）；隔离性（并发控制子系统，确保并发等价串行）；持久性（恢复管理子系统，保证提交结果永久有效）。

• 介质失效恢复（必考）：

  • 考题： 介质失效（磁盘坏了）恢复时，对“上一检查点”以前的已提交事务，要不要 Redo？
  • 核心点： 要 Redo！
  • 原因： 介质失效意味着磁盘数据全丢。恢复是基于 后备副本（Backup） 进行的，副本通常很旧。虽然检查点保证了当时数据入盘，但那个盘已经坏了。所以必须从副本时间点开始，重做所有已提交事务。

• 运行记录（Log）管理：

  • 考题： 什么时候可以清空运行记录（CTL/Log）？
  • 核心点： 只有在完成了新的 数据库转储（备份） 后，旧的日志才能清空。

• 系统故障恢复：

  • 考题： 系统崩溃如何恢复？
  • 答题要点： 正向扫描日志找到提交/未完成事务，构建 REDO 队列与 UNDO 队列；逆向扫描对未完成事务执行 UNDO；再正向扫描对已提交事务执行 REDO，恢复一致状态。

• 介质故障恢复：

  • 考题： 介质损坏的恢复步骤？
  • 答题要点： 装载最近的数据库备份（必要时含转储开始的日志）；再装载备份后的日志，正向重做所有已提交事务；确保数据库恢复到故障前一致状态。

• 事务故障恢复：

  • 考题： 单个事务失败如何恢复？
  • 答题要点： 从日志尾部逆向扫描，找出该事务的更新操作，逐条写回“旧值”实现 UNDO，直至事务开始标记。

• 检查点恢复：

  • 考题： 使用检查点方法的步骤？
  • 答题要点： 从重启文件定位最近检查点，得到 Active-List；建立 UNDO-LIST/REDO-LIST；从检查点向后扫描日志，将新事务加入 UNDO、提交事务移动到 REDO；完成扫描后，对 UNDO 事务执行撤销，对 REDO 事务执行重做。

• 数据库镜像：

  • 考题： 什么是数据库镜像，有何用途？
  • 答题要点： DBMS 自动将数据库或关键数据实时复制到另一磁盘，保持主/镜像一致。可在介质故障时快速切换并恢复，也可在正常情况下为读请求分担压力，提高可用性。