数据库系统工程师 - 终极通关知识库
没有找到匹配的知识点
请尝试输入其他关键词，例如“CPU”、“范式”、“锁”或“SQL”。
第一模块：计算机系统与安全基础
CPU 指挥中心：那些长得很像的寄存器
程序计数器 (PC)
指令寄存器 (IR)
指令译码器 (ID)
题目：在 CPU 的控制器中，用于存放当前正在执行指令的寄存器是（ ）。
A. 模型寄存器 B. 指令寄存器 C. 程序计数器 D. 状态寄存器
流水线计算：考试拿分大户
※ Δt (流水线周期) = 各工序中最长的那一段。
题目：某指令流水线分为“取指、分析、执行”三段，时间分别为 2ns, 3ns, 1ns。执行 100 条指令总时间是？
2. 第一条指令耗时：2 + 3 + 1 = 6ns。
3. 总时间：6 + (100 - 1) * 3 = 303ns。
磁盘与存储：不要被干扰项骗了
Cache 高速缓存
局部性理论
时间局部性：刚用过的马上还用（循环）。
空间局部性：访问了 A，隔壁的 B 也要用（数组）。
题目：某磁盘转速 6000转/分，寻道时间 10ms，则其平均等待时间是？
2. 计算一圈时间：60,000ms / 6000转 = 10ms/转。
3. 平均等待时间 = 转半圈时间 = 10 / 2 = 5ms。
可靠性模型：串联与并联
串联系统 (圣诞灯)
可靠性 R = R₁ * R₂ * ...
并联系统 (双引擎)
可靠性 R = 1 - (1 - R₁)(1 - R₂)...
安全、病毒与纠错码
数字信封组合
对称加密：打包大文件（AES/DES/IDEA）。
非对称加密：加密那把对称钥匙（RSA）。
海明码公式 (必背)
n 为原始数据位，k 为校验位。
- MD5 信息摘要位数为：128 位
- Flynn 分类法中商用并行机主流是：MIMD
- 宏病毒主要攻击的对象是：Word / Excel 文档
死锁产生的核心是多个进程在循环等待对方手中不可剥夺的资源。操作系统在内存里通过 银行家算法 进行动态分配彩排：
- 核心逻辑：比对当前系统剩余可用资源（Available）与各进程剩余所需资源（Need）。
- 放贷铁律：只有当可用资源能完全满足某个进程的全部剩余需求时，才将资源分给该进程。该进程完工后，会将其先前占用的所有资源（Allocation）全部安全归还给金库。
在网络环境下，确保数据库和报文安全必须满足三个物理指标：
- 非对称加密（防偷看）：使用一对两把不同的钥匙。**“想发给谁，就用谁的公钥加锁；谁收文件，就用谁的私钥开锁”**。私钥绝不网传。
- 数字签名（防伪造）：发送方用自己绝不外传的**私钥盖戳**，接收方用发送方的**公钥验戳**。以此确立发送者的真实身份。
- 信息摘要（防篡改）：利用 MD5 / SHA 等哈希算法提取文件的数字指纹。具备极其变态的 **雪崩效应**（原文哪怕变动一个字节，摘要值就会天翻地覆地剧变），用以保证数据完整性。
上午场必考的两类纯数学得分大题公式：
- 串联系统可靠性：一损俱损，总可靠性等于各部件可靠性相乘：R_总 = R_1 × R_2（设备越多，整体越不可靠）。
- 并联系统可靠性：互为备胎，总故障率等于各部件故障率相乘：R_总 = 1 - (1 - R_1) × (1 - R_2)（设备越多，整体越稳固）。
- 数据挖掘关联规则：
1. **支持度 (Support)** = 包含 A 和 B 的订单数 ÷ 总订单数（看全局频率）
2. **置信度 (Confidence)** = 包含 A 和 B 的订单数 ÷ 购买了 A 的订单数（看条件概率）
| 权利类别 | 保护对象 | 保护期限 | 核心特性 |
| 商标权 | 品牌名称、Logo招牌 | 10年 | 到期前申请续展，可**无限期续展** |
| 专利权 | 发明创造、外观设计 | 发明20年 / 外观10年 | 必须**主动向国家申请**才能获得 |
| 著作权 (版权) | 软件源代码、软件文档 | 作者终生 + 死后50年 | **创作完成即自动产生**，无需注册 |
第二模块：关系代数与数据库设计理论
1. 数据库设计六阶段
2. E-R 图与逻辑转换铁律
E-R 图三大元素：
- 矩形：实体（如：学生、课程）。
- 椭圆：属性（如：姓名、年龄）。
- 菱形：联系（如：选课、属于）。
1. 1:1 联系：可在任意一方加外键，不需要新表。
2. 1:N 联系：把“1”端的主键加到“N”端做外键（例：学院号加到学生表）。
3. M:N 联系：必须独立建新表。主键为两端实体主键的组合。
情景：教师(工号)和设备(设备号)是 M:N 关系，申请时记录“申请日期”。
问：生成的“申请关系模式”中，主键是什么？
解析：多对多联系转换后的新表，必须由两端的物理主键共同构成复合主键。
3. 关系运算：数据的数学舞步
- σ 选择 (Selection)：横着切。过滤“行”（WHERE）。
- π 投影 (Projection)：竖着切。挑选“列”（SELECT）。
- × 笛卡尔积：无脑配对。R(m列,n行) × S(p列,q行) = (m+p)列, (n*q)行。
- ⋈ 自然连接：等值连接并去重。自动寻找同名列进行匹配。
题目：关系 R(3列, 4行)，关系 S(5列, 2行)。执行 R × S 后，结果有几列几行？
解析：列数相加 (3+5)，行数相乘 (4*2)。
4. 范式理论：数据库的“拆分手术”
1NF：原子性
每一格只能有一个值，不能再拆分。（如：地址不能同时存省和市）
2NF：消除部分依赖
非主属性必须依赖【整个】复合主键，不能只依赖其中一部分。
3NF：消除传递依赖
非主属性不能通过另一个非主属性间接依赖主键。（如：学号→系名，系名→系主任）
“供应商表 S 中存在 Sno → Zip，Zip → City。” 该表属于第几范式？
解析：由于存在 Zip → City 的传递依赖，所以不满足 3NF，最高只到 2NF。
5. 树：索引的物理基石
二叉树遍历规律
左子树永远在右子树前面！ 根的位置决定名称：根在前（前序）、根在后（后序）、根在中（中序）。
一颗树：A 是根，左边是 B（B 下面有左儿子 D），右边是 C。
中序遍历结果是？
推导：左(D->B) -> 根(A) -> 右(C)。
B+ 树：数据库索引之王
- 矮胖结构：减少磁盘 IO 次数。
- 叶子节点“手拉手”：底层有双向链表，支持极快的 范围查询。
- 全量数据在底层：非叶子节点只存索引，不存真实数据。
6. 易错点总结 ⚠️
- 自然连接 vs 笛卡尔积：自然连接会自动去掉重复列，笛卡尔积会全部保留。
- 左外连接：左表的所有行必须出现，右表没匹配上的补 NULL。
- 逻辑独立性：对应的是【外模式/模式映像】。
- 物理独立性：对应的是【模式/内模式映像】。
1. 三级模式与两级映像
- 外模式 (用户级)：用户看到的视图。保证 逻辑独立性。
- 模式 (概念级)：全局的逻辑结构（所有的表）。
- 内模式 (物理级)：数据的物理存储和索引。保证 物理独立性。
两级映像关系：
1. 外模式/模式映像：对应逻辑独立性（表结构变，视图可不变）。
2. 模式/内模式映像：对应物理独立性（存盘变，表结构可不变）。
为了解决传统二叉树在海量数据下“树高暴增”导致磁盘 I/O 次数过多的致命伤，数据库引入了矮胖的 B+ 树。
- 结构特征：非叶子节点（树枝）**绝对不存真实行数据**，只存小巧的“索引键”。这使得单个节点能分出成百上千个树杈（高扇出），极大地压缩了树的高度。
- 叶子链表：所有真实的行数据全部存放在最底层的叶子节点上，且叶子节点之间使用**双向链表**首尾相连。
第三模块：SQL 语言与高级数据库对象
1. 表结构设计与五大约束
- PRIMARY KEY：主键。唯一标识，不能为空（身份证号）。
- NOT NULL：非空。这格必须填。
- UNIQUE：唯一。不能重复（手机号）。
- CHECK：检查。限制范围（如：性别只能是'男'或'女'）。
- FOREIGN KEY：外键。连接两张表的纽带。
题目：在 SQL 语句中，用于限制“性别”列只允许输入“男”或“女”的约束关键字是（ ）。
解析：CHECK 约束用于指定列中的值必须满足的条件。
2. DML 数据操纵：增、删、改
INSERT INTO (增)
INSERT INTO 表名 (列1, 列2) VALUES (值1, 值2);
UPDATE (改)
UPDATE 表名 SET 列 = 新值 WHERE 条件;
DELETE (删)
DELETE FROM 表名 WHERE 条件;
场景：如果执行 DELETE FROM Students; 且没有写 WHERE 子句，后果是？
解析：不带条件的 DELETE 会清空表中的所有记录，但表结构（舞台）依然存在。
3. 事务：数据的“后悔药”
- COMMIT：提交。操作正式生效，不可撤销。
- ROLLBACK：回滚。操作作废，回到最初的状态。
4. 易错点总结 ⚠️
- 符号问题：SQL 中的逗号、括号、单引号必须是 英文半角。
- 主键唯一性：一张表只能有一个主键（可以是多个字段组成的复合主键）。
- NULL 判断：判断是否为空要用
IS NULL，不能用= NULL。 - 约束名称：复杂的 CHECK 约束常出现在软考填空题中。
1. 视图 (View)：虚拟的“滤镜”
- 安全性：隐藏敏感字段（如只给看姓名，不给看学号）。
- 简化性：把复杂的 JOIN 包装成一张假表。
- 独立性：原表结构变了，只要视图定义跟着改，前端程序就不用动。
题目：如果往视图里插入数据，原始表会同步变化吗？
解析：视图是实时窗口，操作视图本质上是数据库在后台代为操作原表。但前提是该视图必须是可更新的。
2. 索引 (Index)：搜索的“传送门”
存放位置： 索引是确定的存取路径，存储在 磁盘 上。
题目：往一个拥有 10 个索引的表里插入 100 万条数据，速度比没有索引的表（ ）。
A. 快很多 B. 一样 C. 慢得多
解析：每插入一行，数据库必须同步更新 10 个 B+ 树索引，开销巨大。
3. 触发器 (Trigger)：自动化的“警卫”
- 事件：INSERT, UPDATE, DELETE。
- 时间：BEFORE（发生前校验）或 AFTER（发生后记账）。
- 应用：自动记录审计日志。
4. 安全管理 (GRANT/REVOKE)
题目：授权时为什么用 GRANT SELECT ON 而不是 FROM？
4. 下午题 SQL 实战知识体系
套路一：聚合统计与分组过滤 (Group By)
逻辑： 只要使用了 SUM/AVG 等聚合函数，非计算字段必须进入 GROUP BY；对汇总后的结果筛选必须用 HAVING。
SELECT c.CustName, SUM(o.Qty) AS Total
FROM Orders o
JOIN Customers c ON o.CustID = c.CustID
JOIN Products p ON o.ProductID = p.ProductID
WHERE p.Category = '家电' -- 聚合前的初筛
GROUP BY c.CustName
ORDER BY Total DESC;
套路二：否定型查询 (排除法逻辑)
逻辑： 面对“从来没有”、“不曾购买”这类条件，先用子查询抓出“做过的人”组成黑名单，再用 NOT IN 剔除。
SELECT CustID, CustName FROM Customers
WHERE CustID NOT IN (
SELECT o.CustID FROM Orders o
JOIN Products p ON p.ProductID = o.ProductID
WHERE p.Price > 5000
);
套路三：查漏补缺 (LEFT JOIN 匹配法)
逻辑： 利用左连接保留左表全量的特性。右表（订单表）匹配不上的客户，其关联字段必定是 NULL。
SELECT c.CustName FROM Customers c
LEFT JOIN Orders o ON c.CustID = o.CustID
WHERE o.OrderID IS NULL;
套路四：标量子查询对比 (组对比全局)
逻辑： 当需要将各组的数据（如班级平均分）与全局数据（如全校总平均分）对比时，在 HAVING 后面嵌套一个只返回单值的子查询。
SELECT 班级号 FROM Scores
GROUP BY 班级号
HAVING AVG(分数) > (SELECT AVG(分数) FROM Scores);
套路五：自连接查询 (自己跟自己比)
逻辑： 同一张表起两个别名（如 e 代表员工，m 代表经理），通过连接条件建立逻辑关联。
SELECT e.EmpName FROM Employee e, Employee m
WHERE e.ManagerID = m.EmpID AND e.Salary > m.Salary;
1. NULL 判定：严禁写
= NULL，必须写 IS NULL。2. 执行顺序：FROM ➔ WHERE ➔ GROUP BY ➔ HAVING ➔ SELECT ➔ ORDER BY。
3. 别名使用：在 WHERE 里不能直接引用 SELECT 定义的别名（因为顺序太靠前）。
第四模块：数据库系统架构、并发控制与备份恢复
2. 并发控制：三道防线与两段锁
并发三大异常：
- 丢失修改：两人同时改，后者的覆盖了先前的。
- 读脏数据：读到了别人最终回滚掉的假数据。
- 不可重复读：事务内两次读，结果因别人修改而不同。
题：事务 T1 修改余额还没提交，T2 读取了。随后 T1 因故回滚（ROLLBACK）。T2 读到的是？
解析：只要出现了“未提交即读取”且伴随“回滚”，这就是典型的脏读。
封锁协议等级：
- 一级协议：修改加 X 锁到结束。防【丢失修改】。
- 二级协议：读加 S 锁，读完即放。防【脏读】。
- 三级协议：读加 S 锁，事务结束才放。防【不可重复读】。
核心：事务分为“加锁阶段”和“解锁阶段”。一旦开始解锁，绝不能再申请新锁。
3. 故障恢复：REDO 与 UNDO
UNDO (撤销)
日志中 没有 COMMIT。说明任务夭折，必须回滚数据。
REDO (重做)
日志中 已有 COMMIT。说明任务已成，确保存盘生效。
1. 数据备份与恢复策略 (权衡的艺术)
| 备份类型 | 备份内容 | 恢复速度 | 空间占用 |
|---|---|---|---|
| 完全备份 (Full) | 备份整个数据库 | 最快 (只需这一个包) | 最大 |
| 增量备份 (Incremental) | 仅备份上一次备份后发生变化的数据 | 最慢 (需要全备 + 沿途所有增备包) | 最小 |
| 差异备份 (Differential) | 备份上一次完全备份后发生变化的所有数据 | 中等 (全备 + 最新的一个差备包) | 中等 |
场景：系统周日进行完全备份，周一至周六每天进行差异备份。如果在周四上午硬盘损坏，管理员应如何加载备份进行恢复？
解析：差异备份的特点是“打包自上次全备以来的所有变化”。因此周三凌晨的差异包已经包含了周一、周二、周三的所有数据变动。恢复时只需首尾相加，不需要中间的过渡包。
2. 分布式数据库体系
四大透明性 (由高到低)
- 分片透明性 (Fragmentation)：最高级别。用户不需要知道数据是如何被“切碎”的。
- 位置透明性 (Location)：用户不需要知道数据存在哪个城市的机房（物理位置）。
- 局部数据模型透明性：用户不需要知道局部场地使用的是什么数据模型（关系型还是网状等）。
表的分片方式 (数据怎么切碎)
水平分片 (按“行”切)
以元组（行）为单位进行划分。例如：将北京客户的整行数据放 A 机房，广州客户的放 B 机房。
垂直分片 (按“列”切)
以属性（列）为单位进行划分。例如：将用户的“基本信息”放一处，“隐私信息”放另一处。（注意：切开的每一块必须都包含主键，以便日后连接还原）。
题：用户编写程序时，不需要知道某张表的数据到底是“按行切”存在了多台服务器上，还是“按列切”存在了多台服务器上，这属于什么透明性？
解析：只要题干中强调了对“切割规则（按行/按列）”的隐藏，就是考分片透明性。如果题干强调的是“不知道在哪个服务器”，则是考位置透明性。
3. NoSQL 非关系型数据库选型
- 键值对 (Key-Value) 数据库 🗝️：
- 代表： Redis
- 特点： 数据存在内存中，速度极快；结构像查字典一样简单。
- 场景： 双 11 秒杀、热点新闻缓存、排行榜。
- 文档型 (Document) 数据库 📄：
- 代表： MongoDB
- 特点： 数据存为类似 JSON 的格式，不需要固定的表格结构，每一行拥有的字段可以完全不同。
- 场景： 结构多变的海量数据，如博客文章、短视频评论、用户行为日志。
如果要开发一个大型内容社区，帖子内容长短不一，且后期极有可能频繁增加新字段（如打赏数、点赞列表）。
选型建议：首选 MongoDB。因为它是文档型数据库，格式自由，完美契合“海量且结构不固定”的业务需求，无需像 MySQL 那样痛苦地修改表结构（ALTER TABLE）。
1. 系统设计基础：DFD 与 DD
一、 数据流图 (DFD) 四大元素与铁律
- 外部实体 🧑💼： 系统外的人或机构（正方形）。
- 加工 ⚙️： 处理数据的动作（圆形/圆角矩形）。
- 数据存储 🗄️： 存放数据的地方（右开口矩形）。
- 数据流 ➡️： 搬运数据的管道（箭头线）。
外部实体 ↔ 数据存储（错！）
外部实体 ↔ 外部实体（错！）
数据存储 ↔ 数据存储（错！）
- 两大经典错误： 【黑洞】(只有输入无输出)；【奇迹】(只有输出无输入)。
- 父子图平衡： 顶层图(父)与0层图(子)的输入/输出数据流在数量和名称上必须 100% 匹配。
二、 数据字典 (DD) 密码本
+ : 和（连接两个必填项）
[...] : 任选其一（多选一，如 [男 | 女]）
(...) : 可选（可有可无）
{...} : 重复（出现 0 次或 N 次）
2. 数据库安全性：权限控制
- GRANT：授予权限。
GRANT SELECT, UPDATE ON 员工表 TO 小明; - REVOKE：收回权限。
REVOKE UPDATE ON 员工表 FROM 小明; - WITH GRANT OPTION：权限传递。如果 DBA 收回了上级的权限，下级通过该选项获得的权限会被级联收回 (Cascade)。
3. 事务控制、并发与恢复 (核心必考)
一、 ACID 四大神兽
- A (原子性 Atomicity)：同生共死，不可分割（由日志的 undo 保证）。
- C (一致性 Consistency)：操作前后，总量守恒、符合业务规则。
- I (隔离性 Isolation)：多用户并发时互不干扰，仿佛单机运行。
- D (持久性 Durability)：一旦提交(Commit)，永久保存，断电不丢失（由日志的 redo 保证）。
二、 并发三大幽灵 (隔离性遭破坏)
- 脏读 (Dirty Read)：读到了别人“还没提交、随时会撤销”的临时数据。
- 丢失更新 (Lost Update)：两人同时修改，后提交的人把前一个人的修改覆盖了。
- 不可重复读 (Non-repeatable Read)：同一次事务里看两次，数据竟然变了（被别人提交改了）。
三、 封锁协议 (Locking)
| 锁类型 | 遇到 X 锁请求 | 遇到 S 锁请求 |
|---|---|---|
| X 锁 (排他/写锁) | 冲突 (阻塞) 🚫 | 冲突 (阻塞) 🚫 |
| S 锁 (共享/读锁) | 冲突 (阻塞) 🚫 | 兼容 (一起读) ✅ |
注意：两个事务互相等待对方释放锁，导致永久卡死，称为死锁 (Deadlock) 💀。
四、 日志文件与系统恢复
先写日志原则 (WAL)： 修改数据库物理文件前，必须先在日记本(日志文件)里记录动作！
场景：系统崩溃后重启，DBA 检查日志文件：
事务 T1：有 BEGIN，且有 COMMIT。
事务 T2：有 BEGIN，但没有 COMMIT。
对 T2 使用 UNDO（撤销）： 因为它没做完就断电了，要确保原子性 (A)，擦除痕迹，当作没发生过。
在系统实施与测试阶段，根据是否查阅源代码，测试方法分为两大派系：
- 黑盒测试（功能测试）：把程序看作不透光的黑盒子。完全不考虑内部代码结构，只根据需求说明书进行输入输出验证（如边界值分析、等价类划分）。
- 白盒测试（结构测试）：把程序看作透明的盒子。测试人员必须精通内部代码，通过设计测试用例来覆盖程序内部的所有逻辑路径、分支和循环体。
分布式透明性 的核心定义是：**向用户屏蔽底层物理拆分的复杂细节**（计算机里“透明” = 看不见）。
- 分片透明（最高级别）：用户完全不知道数据被切分和打碎了。
- 位置透明：用户知道数据被拆分了，但不需要知道它们具体存放在哪台物理服务器上。
- 局部数据模型透明：用户不需要管各个节点用的是 MySQL 还是 Oracle，统统当成普通的 SQL 库来用。