我的博客

4.6 恢复、安全与优化

4.62026-11-03 11:33:00

本篇定位：数据库的"运维保障层"——故障恢复（日志/备份）、安全控制（授权/视图）、性能优化（索引）。9 年真题直接命中 15+ 题，2026 年集中爆发 6 题（单21/33/47/51/55、多94/99），是数据库篇近年最活跃的知识块。题型：①日志机制（先写日志、检查点、日志满）；②备份策略（完整/差异/增量）；③视图本质（不存储数据、不提高效率）；④索引（何时建/何时删/建什么列）。2027 预测 2–3 题：索引、视图、日志恢复——高概率。 数据依据：01-真题/真题文本/ + 01-真题/考点汇总/；答案以专业判断为准。 阅读提示：视图=外模式衔接 4.1；锁等待衔接 4.5；备份与第 7 篇容灾（RPO/RTO）呼应；安全授权与 7.3 访问控制呼应。

一、考点定位（本章真题统计）

考点真题锚点频次考法
日志与恢复2020 单51、2021 单52、2026 单47/513 年 4 题先写日志、检查点作用、日志满只能读、转储冗余
备份策略2020 单50、2025 单742 年差异备份含义、完整+差异恢复最快
视图2018 单53、2019 单39、2022 多88、2026 单214 年 4 题视图定义存字典、隐藏数据、不提高效率
索引2019 单27、2021 单51/55、2024 多92、2026 单33/55/多945 年 7 题索引作用、失效、何时删、建什么列
优化策略2022 单51、2024 单51、2026 多993 年 3 题数据日志索引分开放、UNION 优化、减少 IO

命题规律：本章是数据库篇近年增量的主战场（2026 年 6 题），两大主线：①日志/备份/恢复（可靠性）；②索引/视图/优化（性能与安全）。2027 预测 2–3 题：索引选择（建/删/列）、视图本质、日志恢复。核心能力：索引"何时建何时删建哪列"三问 + 视图"三不"（不存储/不提高效率/不提高插入）。

二、知识框架（先搭骨架）

数据库恢复（靠冗余数据，2026 单51）
├── 冗余数据 = 日志文件 + 数据库后备副本
├── 日志（预写日志 WAL，2026 单47）
│   ├── 先写日志后写数据（保证可恢复）
│   ├── 检查点：提高恢复效率（2020 单51）
│   └── 日志满：只能读不能写（2021 单52）
├── 备份（2020 单50、2025 单74）
│   ├── 完全备份：全部数据（基础）
│   ├── 差异备份：上次完全备份后修改的数据
│   └── 增量备份：上次任意备份后修改的数据
│   └── 恢复最快组合：完整备份+差异备份（2025 单74）
└── 故障类型：事务故障（UNDO）、系统故障（UNDO+REDO）、介质故障（重装+恢复）

数据库安全
├── 授权 GRANT/REVOKE（4.2 已讲）+ 视图隐藏数据（2019 单39）
├── 视图安全机制：只暴露需要看的列/行
└── 列级/行级授权（2020 单45）

视图（View，虚表）
├── 不存储数据（2022 多88、2026 单21）
├── 不提高访问效率（2026 单21 D 错误）
├── 提供数据安全机制（隐藏无权数据）
├── 体现逻辑独立性（表结构变、视图不变）
└── 视图定义存数据字典（2018 单53）

索引（Index，查询加速器）
├── 作用：提高查询速度（2019 单27）
├── 建立：CREATE INDEX；一个表可多个索引（2024 多92）
├── 删除：DROP INDEX（不是 DELETE INDEX）
├── 代价：占存储、降低增删改速度（2021 单55、2026 多94）
├── 何时建：查询频繁的列、复合索引按查询条件顺序（2024 单50）
├── 何时不建：重复值超 80%（2026 单33）、更新频繁（2026 单55）
└── 失效：索引列上套函数→全表扫描（2021 单51）

查询优化
├── 数据/日志/索引分设备（2022 单51）
├── 避免 SELECT *、索引覆盖、分区表、查询缓存（2026 多99）
└── 适当冗余减少连接（2022 单51 D）

一句话记忆：恢复靠冗余（日志+备份）→ 先写日志、检查点提效率、日志满只读 → 备份三兄弟（完全/差异/增量）→ 视图三不（不存储/不提效/不建数据）→ 索引"建查询列、删更新列、忌函数套列"。

三、考点详解

3.1 日志与恢复（2026 单47、2020 单51、2021 单52、2026 单51，必考）

精确定义：日志文件 = 记录事务对数据库的每次更新操作（旧值/新值）的文件，是数据库恢复的依据。

三条必背：

  1. 先写日志、后写数据库（预写日志 WAL，2026 单47 选 C）——保证系统故障时能用日志恢复（否则数据改了日志没记，无法还原）；
  2. 检查点记录的作用 = 提高系统故障后的恢复效率（2020 单51 选 C）——恢复时不用从头扫描全部日志，从检查点开始即可；其他错误项：日志写入顺序必须与并发事务执行时间次序一致（A 错）；必须是先写数据库后写日志（B 错——反了）；事务故障恢复也要用日志（D 错）；
  3. 日志满 → 只能执行读操作，不能执行更改/备份等写操作（2021 单52 选 B）——日志没空间记录新更新，为保证可恢复性禁止写。

恢复用的冗余数据（2026 单51 选 C）：日志文件 + 数据库后备副本（A/B/D 里的"应用程序、审计档案、数据字典"不是恢复的冗余数据）。

口诀：先日志后数据；检查点提速；日志满只读；恢复靠日志+备份。

3.2 备份策略（2020 单50、2025 单74）

三种备份（必背）：

  • 完全备份：备份全部数据（耗时最长，是恢复的基线）；
  • 差异备份：备份上次完全备份之后修改的数据（2020 单50 选 D）；
  • 增量备份：备份上次任意备份（完全或增量）之后修改的数据（最少、最快，但恢复要按序叠加）。

恢复速度（2025 单74 选 A）：完整备份 + 差异备份组合的还原速度最快（只需还原完整备份 + 最近一次差异备份，两次操作）；完整+增量要按序还原多次增量（慢）。

辨析：差异 vs 增量——差异备份的"基准"永远是上次完全备份；增量备份的"基准"是上次任意备份。差异备份比增量备份数据多但恢复快。口诀：差异以完全为基准、增量以上次为基准。

3.3 视图（View）（2026 单21、2022 多88、2019 单39、2018 单53，必考）

精确定义：视图 = 从一个或多个基本表（或其他视图）导出的虚表——只保存定义、不保存数据（数据仍存在基本表中）。

视图的特性（2022 多88、2026 单21）：

  • ✅ 不存储数据，但可通过视图访问数据（2022 多88 A 对、2026 单21 A 对）；
  • ✅ 提供数据安全机制（只暴露需要的列/行，隐藏无权数据——2019 单39 选 A）；
  • ✅ 体现逻辑独立性（基本表结构变化时，视图可保持不变）；
  • ❌ 不能提高访问效率（2026 单21 选 D——"视图能够提高对数据库的访问效率"是错误说法；2022 多88 也把"视图不能提高访问效率"列为对）。

2018 单53：建立视图后，数据字典中存放的是视图的定义（选 C；不是查询语句的展开、也不是表数据）。

口诀：视图三不=不存储数据、不提高效率、不是基本表；视图一存=存定义。

3.4 索引（2026 单33/55/多94、2024 多92/单50、2021 单51/55、2019 单27，必考大户）

精确定义：索引 = 建立在表列上的辅助数据结构（类似书的目录），提高查询（检索）速度，但占用额外存储、降低增删改速度。

⚠️ 索引属于哪一层？在表里怎么"表示"？（问得最多的一个点）

  • 索引不在表结构里表示：关系模式 R(U, F) 里只有属性集 U 和函数依赖 F，没有索引；CREATE TABLE 的列定义里一般也看不到它。索引是表之外的独立对象——有自己的名字，靠 ON 表名 挂在表上，可单独建、单独删；但它依附于表（DROP TABLE 会把该表的索引一起带走）。
  • 它属于三级模式的哪一级？——内模式（存储模式），与"存储文件"同层，描述的是"数据怎么存、怎么找"（存取路径）。这与"逻辑设计出关系模式、物理设计出索引"是同一件事（2025 单54 的阶段判定）。
  • "表示"一个索引只需要三样东西：索引名 + 所属表 + 索引列（可多列，且有序），再加"是否唯一"。三种写法：
写法语法示例说明
单独建（标准写法）CREATE INDEX idx_name ON 学生(姓名);索引名 + ON 表(列)；加 UNIQUE 即唯一索引
建表时顺带定义CREATE TABLE 学生(…, INDEX idx_name(姓名));MySQL 风格，KEY 同义
由约束隐式创建… 学号 CHAR(8) PRIMARY KEY, …主流数据库里主键 / UNIQUE 都由索引实现 → 自动建索引，不用手写
  • 删除：DROP INDEX 索引名;（不是 DELETE INDEX，2024 多92）；查看：SHOW INDEX FROM 表名;（MySQL）。
  • 一句话：索引 = 内模式里的一个独立对象，用"索引名 + ON 表(列)"表示；关系模式里永远不写它。

索引的作用（2019 单27 选 A）：提高查询语句执行效率（不是提高更新效率——更新要维护索引反而变慢）。

索引管理语法（2024 多92 选 ABD）：

  • ✅ 建立索引目的是提高查询速度；
  • ✅ 建立索引用 CREATE INDEX 语句；
  • ❌ 删除索引用 DELETE INDEX 是错误的——应使用 DROP INDEX；
  • ✅ 一个基本表可以建立一个或多个索引（"每表只能一个索引"是错误说法，2026 多94）。

索引的代价（2021 单55、2026 多94）：

  • 创建索引不能提高插入性能（2021 单55 选 A——"创建索引能提高插入性能"是错误说法：插入要同时维护索引，反而变慢）；
  • 索引过多会降低更新（增删改）速度、占用额外存储（2026 多94）。

何时建索引（2024 单50）：

  • 在查询频繁、WHERE 条件常用的列上建；
  • 复合条件（多个列）→ 建复合索引，列顺序按查询条件（2024 单50：条件同时用 Last Name 和 First Name → 建 (Last Name, First Name) 复合索引，选 A）。

何时不建索引（2026 单33、单55）：

  • 重复值超过 80% 的字段不适合建索引（2026 单33 选 B——区分度太低，索引没用）；
  • 更新是性能瓶颈时考虑删除索引（2026 单55 选 B——更新要维护索引，去掉可提速）。

索引失效（2021 单51，必考）：在索引列上套函数（如 substr(phoneno,1,3)='321'）→ 索引失效 → 全表扫描（最慢），应改写为 phoneno LIKE '321%'。

为什么"套函数"就失效？（关键就一句：索引只认它那一列的"原值"）

打个比方：索引 = 一本按 phoneno 从小到大排好序的电话簿。 要查这本电话簿，你手里必须拿着一个 phoneno 的值去翻——这个值就是"钥匙"。

  • phoneno LIKE '321%'：条件直接写在 phoneno 上，钥匙是现成的 '321'。又因为电话簿本身就是按 phoneno 排序的，所有"321 开头"的号码挤在连续的几页里 → 翻到那一页往下看就行 → 快。
  • substr(phoneno,1,3) = '321'：条件写在"把 phoneno 切下前三位"这个加工品上。电话簿里根本没有"前三位"这一栏，这本电话簿只懂"完整 phoneno 的顺序"，不懂"前三位这个加工品的顺序" → 只能从第一页起，每个号码都切一刀、再比一次，一直翻完 100 万条 → 慢（全表扫描）。

精确的因果链（三步，别搞反）：① 钥匙不在手上（条件里没有"直接落在索引列上的值"）→ ② 无法在电话簿/索引上定位起点 → ③ 只能逐行取值、逐行加工、逐行比较 ＝ 把整张表看一遍 ＝ 全表扫描。

所以考场判据就一句：

条件里有没有"直接写在索引列（phoneno）上的值"？有 → 用得上索引；那个值写在函数上 → 失效。

条件里面"直接写在 phoneno 上的值"结论
phoneno = '3211234''3211234'✅ 用得上
phoneno LIKE '321%''321'✅ 用得上
phoneno >= '321''321'✅ 用得上
substr(phoneno,1,3) = '321'没有（'321' 写在 substr(...) 上）❌ 失效

⚠️ 常见误解：substr(phoneno,1,3)='321' 里 '321' 明明直接给了，凭什么说"没钥匙"？

关键：钥匙 = 「值」+「它比较的对象」两样东西，缺一不可。 手上有值，不等于这把钥匙能开索引这扇门。

  • phoneno LIKE '321%'：'321' 比较的对象是 phoneno 本身 → 这把钥匙插的就是索引那把锁 → ✅ 开得了；
  • substr(phoneno,1,3) = '321'：'321' 比较的对象是 substr(phoneno,1,3) → 它插的是另一把锁，插不进索引 → ❌ 开不了。

所以不是"没有钥匙"，而是"这把钥匙开的不是索引那扇门"。

为什么会这样？ 因为索引这本电话簿只懂一件事：phoneno 的顺序。所以只有"phoneno 落在哪个区间"这类提问它才答得上（LIKE '321%' 就等于在问"phoneno 是否落在 ['321','321A') 里"）。而"前三位这个加工品等于几"是关于另一个量的提问，电话簿答不了。

那 DBMS 为什么不自己把 substr(phoneno,1,3)='321' 翻译成 phoneno LIKE '321%'？ 因为通用规则下做不到：f(列) = 常量 这种形式，对任意函数 f（可能是 MD5、可能是取随机数）都无法反推出列的取值范围。所以优化器的通用策略是——索引列一旦被包进函数/表达式，就不拿它来定位。个别数据库确实对少数内置函数做了特判改写，但那是实现细节、不是保证；考试一律按"失效"答。

最值得体会的一点：substr(phoneno,1,3)='321' 与 phoneno LIKE '321%' 在语义上完全等价（电话号码全是数字，两者选出的就是同一批行）。一个能用索引、一个不能用，区别纯粹在于"写法有没有把『关于 phoneno 的条件』明说出来"。

一句话记忆：索引只认它那一列的"原值"，不认任何"加工品"——套函数、做算术、隐式类型转换，都算加工。

凡是"把索引列包进任何计算"的写法都会失效（这类写法叫非 sargable）：

  • substr(phoneno,1,3)='321'（套函数）；year(日期)=2021（套时间函数）；
  • upper(姓名)='ZHANG'（套大小写转换）；phoneno+0=123（套算术）；
  • 隐式类型转换：字符列与数字比较（字符列 = 123）→ 列被隐式转成数字，等于对列套了函数。

改写原则：把函数/计算搬到等号右边（常量一侧），让索引列"素颜"出现：

  • substr(phoneno,1,3)='321' → phoneno LIKE '321%'；
  • year(日期)=2021 → 日期>='2021-01-01' AND 日期<'2022-01-01'；
  • upper(姓名)='ZHANG' → 建函数索引，或干脆按大写存储。

⚠️ LIKE 到底能不能用索引，看通配符位置：

  • LIKE '321%' —— 前缀已知 → 能在有序树上定位到 '321' 这个起点、再沿叶层扫 → ✅ 用得上索引（优化器把它转成范围扫描）；
  • LIKE '%321' / LIKE '%321%' —— 前缀未知 → 无法定位起点 → ❌ 只能全表扫描。
  • 口诀：通配符在开头＝索引废；通配符在结尾＝索引在。

索引三问口诀：建哪列？→查询频繁且区分度高的列；啥时不建？→重复率>80%、更新频繁；啥时失效？→索引列套函数。

【了解层·国考不考，但把"为什么快"讲透——想考 B+ 树细节在数据结构 3.3】

① 它不是"目录表"，是一棵 B+ 树——因为必须支持"边插边查" "单开一张表、逐行记录位置"这种结构，查询和插入都会退化成 O(n)（要一行行比对、找回插入位置），千万级表不可用。真实实现是 B+ 树（平衡多路查找树）：每个节点是一页（page，常见 8KB/16KB），页内有序存放若干"键 + 指针"，且所有叶子同深度（平衡）。树高通常只有 3~4 层 → "在千万行里找一行"变成"读 3~4 个页"。

② 索引项记的是"键值 + 行标识"，不是"行列位置"

  • 不必记"列位置"：索引只为它建的那一列/几列服务；要取别的列，就按行标识回表读整行。
  • 行标识（RID）有两种形态，对应两类索引：
    • 非聚集索引（二级索引）：叶子存 (索引列值, RID)，查到后还要按 RID 再读一次数据页 → 叫 回表。InnoDB 的 RID 就是主键值（回表 = 再走一次主键树，这也是 InnoDB 主键要"短、单调递增"的原因）；Oracle/PostgreSQL 是物理地址（文件号+页号+行槽号）。
    • 聚集索引：数据行本身就按键值物理排序存放，索引的叶层就是数据本身 → 不记任何"位置"，查到即拿到。每表只能有一个聚集索引（数据的物理顺序只能有一种）。
  • 粒度是页不是"行列"：磁盘 I/O 以页为单位，索引记的是"页 + 页内槽号"。

③ CREATE INDEX 那一刻，DBMS 做了六件事

  1. 写元数据：在**数据字典（系统表）**里登记索引名、所属表、索引列、唯一性（4.4 "数据字典里存放索引的定义"就是这一步）；
  2. 分配存储：在表空间里给索引分配段/文件（如 InnoDB 的 .ibd 中的索引页）；
  3. 读全表 + 排序：扫描表按键值排序（数据量大就外部排序、溢写临时文件）；
  4. 自底向上建树（批量装载）：排好序的结果分批装入叶子页，叶页之间用双向链表串起来（范围查询快的根本原因），再逐层向上生成内部节点到根页——不是一条条插入；
  5. 收集统计信息：基数/选择率/树高，供优化器估代价；
  6. 此后每次增删改都同步维护这棵树：插入要定位、可能触发页分裂，删除可能页合并 → 这就是"索引拖慢增删改"的物理原因（2021 单55）。

④ 省了多少 I/O？拿数字看 1000 万行学生表、一行 200B → 数据约 2GB，页 16KB → 约 13 万个数据页。

  • 无索引（WHERE 姓名='张三'）：全表扫描，最坏读 13 万页；
  • 建姓名索引：索引项约 40B → 一页装约 400 项 → 叶层约 2.5 万页 → 上一层 63 页 → 根 1 页，树高 3 → 路径 = 根（常驻内存 0 次 I/O）→ 1 次内部页 → 1 次叶子页 → 1 次回表 ≈ 3~4 次页读。
  • 13 万次 vs 3~4 次，这就是索引的全部威力。
  • 范围查询（BETWEEN、LIKE '张%'）：定位到起点叶子后沿叶层链表顺序扫，不用回根 → 这才是"B+ 树对范围友好"（哈希索引做不到，见横向扩展第 5 条；哈希只在等值查询有优势）；
  • 覆盖索引：要查的列全在索引里（SELECT 姓名 FROM 学生）→ 不用回表，再省一次 I/O（2026 多99 的"索引覆盖"）。

⑤ DBMS 之下，操作系统与存储层做了什么 DBMS 不直接读盘，中间隔着两层缓存：

  1. DBMS 缓冲池（Buffer Pool）：内存页缓存，所有请求先问它——命中则零磁盘 I/O（根页通常常驻于此），未命中才物理读；
  2. OS 页缓存（Page Cache）：DBMS 调 pread(页) 时 OS 先查自己的缓存；仍未命中才由存储驱动发起真磁盘 I/O（SSD 闪存页 / HDD 寻道+旋转）；
  3. DBMS 常绕过 OS 缓存：用 O_DIRECT 之类直接 I/O，避免"缓冲池一份、OS 缓存又一份"的双缓存白占内存；
  4. 物理本质：把"顺序扫完 N 个页"换成"几次随机页读 + 叶层顺序扫"——随机读虽慢，但次数从十万级降到个位数，这笔账稳赢。

一句话收口：索引不是"另存一张目录表"，而是一棵按索引键有序、以页为单位、叶层带链表的 B+ 树；它靠"把查找从全表扫描降为两三次页读"加速，代价是占空间 + 每次增删改都要维护它。

3.5 查询优化（2022 单51、2026 多99）

2022 单51（不能优化）：将数据、日志、索引放在同一 I/O 设备上（选 A——应分开放，减少 I/O 竞争）。

B / C / D 三个"能优化"的措施逐个解释：

  • B. 分割数据表、减少表的尺寸 → 表小 = 页少 = 扫描要读的页少（就是上面"13 万页 vs 3~4 页"同一笔账）；
  • C. 适当数据冗余、减少表间的连接操作 → 反规范化：把常一起查的列冗余进一张表，省掉 JOIN（JOIN 要读两张表还要做匹配）；
  • D. 在 IN 后面值的列表中，把出现频繁的值放在最前面 → IN 的语义是 所在系 IN ('计算机','金融') = "列的值是否等于列表中某一个"，等价于 所在系='计算机' OR 所在系='金融'。若按这串 OR 顺序求值且短路（命中即停），则把最常命中的值排最前能让平均比较次数最少——与"把过滤性最强的条件放最前"是同一思路。
    • ⚠️ 现实要知道：主流优化器会按代价自行重排谓词、并把 IN 转成哈希/集合查找，此时列表顺序几乎不影响性能。所以 D 是"方向不算错、现代实现里收益趋近于零"的经验性写法——它能被算作"能优化"，是因为它不会让查询变慢；而 A 是原理上就错、会主动加剧 I/O 竞争，所以答案 A。

2026 多99（减少 IO 的策略，全选 ABCD）：索引覆盖（查询列都在索引里，不用回表）、分区表（只扫相关分区）、查询缓存（结果复用）、避免 SELECT *（只取需要的列）。

3.7 数据库安全控制的对象与手段（补强；2025 多90）

控制对象含义手段
非法用户非授权者进入系统身份认证、口令策略、连接审计
非法操作越权读/改/删GRANT/REVOKE 授权、视图、存取控制（DAC/MAC）
无意义/错误数据破坏完整性完整性约束、CHECK、触发器
数据泄露/被窃传输或存储被截获加密、脱敏、审计日志
  • 视图在这里是"安全 + 逻辑独立性"双用途：只暴露部分行/列。
  • 总原则：最小权限＋职责分离＋审计留痕（事后追责）。
  • 真题口径（2025 多90）：安全控制对象含"非法用户、非法操作、无意义/错误数据"；"防止数据冗余"不是安全控制对象（那是规范化/设计优化的目标，别混）。

四、易错坑汇总（命题人惯用陷阱）

  1. 先写日志后写数据库（2026 单47）——"先写数据库后写日志"是错误说法（2020 单51 B 项反着说）。
  2. 视图不能提高访问效率（2026 单21、2022 多88）——"视图能提高访问效率"是错误说法（视图只是虚表，查询还要查基本表）。
  3. 删除索引用 DROP INDEX（2024 多92）——"DELETE INDEX"错误（DELETE 是删数据行，DROP 是删结构对象）。
  4. 索引降低插入速度（2021 单55）——"创建索引能提高插入性能"错误（插入要同步维护索引）。
  5. 重复值 80% 不建索引（2026 单33）——区分度太低；"重复值越多越该建索引"错误（恰好相反）。
  6. 更新瓶颈时删索引（2026 单55）——"更新慢时加索引"错误（加索引让更新更慢）。
  7. 索引列套函数失效（2021 单51）——substr(列) 让索引失效；"函数不影响索引使用"错误。
  8. 差异 vs 增量基准（2020 单50）——差异=上次完全备份后；增量=上次任意备份后；"差异备份基准是上次差异备份"错误。
  9. 恢复冗余=日志+后备副本（2026 单51）——"应用程序/数据字典是恢复冗余"错误。
  10. 日志满只能读（2021 单52）——"日志满后一切操作照常"错误（写操作被禁止）。

五、横向扩展（防漏网：本章边界内、真题尚未考但可能补考的点）

说明：横向扩展覆盖"大纲范围内但 9 年真题未考过"的知识，标注【新增概率】供取舍。

  1. UNDO 与 REDO 日志【中】：事务故障→UNDO（回滚未提交）；系统故障→UNDO+REDO（未提交回滚、已提交重做）——日志恢复机制，高概率补考点。
  2. RPO 与 RTO【中】：RPO=允许丢失的数据量（决定备份频率）、RTO=恢复所需时间（2020 单77 考过备份间隔对应 RPO——注意部分解析标 B（RTO）有争议，应为 A（RPO），见 7.9 章）——与第 7 篇容灾衔接。
  3. RAID 与备份的关系【低】：RAID 防硬件故障，备份防逻辑错误/灾难——概念辨析。
  4. 物化视图【低】：存储查询结果的视图（区别于普通虚表）——名词辨析。
  5. 索引类型（B+ 树/哈希）【中】：数据库常用 B+ 树索引（范围查询友好）、哈希索引（等值查询）——与 3.3 章查找衔接。
  6. 聚集索引 vs 非聚集索引【低】：聚集索引决定物理顺序（每表一个）、非聚集索引独立于数据——名词辨析。
  7. 数据库审计（Audit）【中】：记录用户操作（谁在何时做了什么）——与安全日志呼应（2018 单62 审计行为）。
  8. 自动备份与快照【低】：快照（时间点副本）vs 备份——云计算场景名词。

六、真题演练（代表性真题 + 解析）

例 1（2026 单47） 为了保证数据库中数据的安全可靠和正确有效，系统在进行事务处理时，对数据的插入、删除或修改的全部有关内容应先写入（口径已核）。 A. 索引文件　B. 数据文件　C. 日志文件　D. 数据字典

答案：C。预写日志（先写日志后写数据）——事务更新先记日志，保证故障时可恢复。口诀：先日志后数据。

例 2（2026 单21） 下列关于视图的叙述，错误的是（口径已核）。 A. 视图不存储数据，但可通过视图访问数据 B. 视图提供了一种数据安全机制 C. 视图可以体现数据的逻辑独立性 D. 视图能够提高对数据库的访问效率

答案：D。视图不能提高访问效率（虚表，查询仍要访问基本表）——D 是错误说法。A/B/C 都是视图的正确特性。口诀：视图三不=不存储、不提效、不建数据。

例 3（2024 多92） 下列关于数据库索引的说法，正确的有（口径已核）。 A. 建立索引的目的是提高查询速度 B. 建立索引使用 CREATE INDEX 语句 C. 删除索引使用 DELETE INDEX 语句 D. 一个基本表中能建立一个或多个索引

答案：ABD。删除索引用 DROP INDEX（C 的 DELETE INDEX 错误——DELETE 删数据、DROP 删对象）；其余正确。口诀：建用 CREATE、删用 DROP、一表多索引。

例 4（2026 单33） 不适合建立索引的字段是（口径已核）。 A. 查询频繁的字段　B. 重复值超过 80% 的字段　C. 区分度高的字段　D. 经常用于 WHERE 条件的字段

答案：B。重复值超过 80% → 区分度太低 → 索引几乎无用（甚至拖慢更新）；查询频繁/区分度高/常作 WHERE 条件都是适合建索引的。口诀：重复率高不建索引。

例 5（2025 单74） （口径已核）组合策略的备份还原速度最快。 A. 完整备份和差异备份　B. 部分备份和增量备份 C. 完整备份和增量备份　D. 增量备份和差异备份

答案：A。完整备份+差异备份恢复最快（只需还原完整备份+最近差异备份，两次）；完整+增量要按序叠加多次增量（慢）。口诀：恢复最快=完整+差异。

例 6（2021 单51） 下列查询语句中，执行效率最低（最慢）的是（口径已核）。 A. WHERE phoneno>='321' AND phoneno<'321A' B. WHERE phoneno LIKE '321%' C. WHERE substr(phoneno,1,3)='321' D. WHERE phoneno LIKE '321%'

答案：C。判据：索引列有没有"素颜"出现。

  • C：substr(phoneno,1,3)='321' —— 索引列套了函数 → 树按 phoneno 排序、判断却按 substr 的结果 → 每行都要算一遍 → 索引失效 → 全表扫描 100 万行（最慢）；
  • B / D：LIKE '321%' —— 前缀匹配（通配符在结尾）→ 优化器转成范围扫描 → 用得上索引。⚠️ D 是干扰项：条件与 B 一模一样，只是把 count(*) 换成 count(0)——而 count(0) 里的 0 是常量（不是列），每行都非空，结果与性能和 count(*) 完全相同，所以 D 不比 B 慢；
  • A：phoneno>='321' AND phoneno<'321A' —— 这是"以某前缀开头"的范围写法，索引列素颜、可直接范围定位 → 也用得上索引。⚠️ '321A' 的依据是题干那句"电话号码全部由数字组成"：数字字符的编码都小于字母 'A'，所以"以 321 开头的所有号码"恰好被夹在 左闭右开区间 ['321', '321A') 里（>= 含 '321' 本身，< 排除 '321A' 及其后）。 口诀：索引列套函数=索引失效（2021 单51）。

七、本章小结

  • 一条主线：恢复（日志+备份）→ 日志三律（先写/检查点/满只读）→ 备份三兄弟（完全/差异/增量）→ 视图三不 → 索引三问（建哪列/啥时不建/啥时失效）→ 优化（分设备/减 IO）。
  • 必背判定：先写日志（2026 单47）；检查点提效率（2020 单51）；日志满只读（2021 单52）；视图不提效（2026 单21、2022 多88）；DROP INDEX（2024 多92）；重复值 80% 不建索引（2026 单33）；索引列套函数失效（2021 单51）；完整+差异恢复最快（2025 单74）。
  • 衔接预告：日志 UNDO/REDO→4.5 事务；RPO/RTO→7.9 金融合规；索引 B+ 树→3.3 查找；授权→7.3 访问控制。
计算机专业课金管局一本通