简介《数据库原理与应用第四版》配套PDF是一份面向高校“数据库原理”课程学习者与备考者的复习资料聚焦数据库基础概念、数据模型、三层模式结构与数据库系统组成等核心知识模块也适合作为考研基础课或期末考前快速梳理的参考。包体为单个PDF文件压缩后约399KB内容以章节要点与典型问答为主从数据、数据库、DBMS到数据库系统特点均有归纳。目前已有4854人学习/下载使用热度良好。内容预览中可见复习题覆盖填空、选择与四道问答题具体包括数据与数据库语义、DBMS作用、三级模式与两级映像保证的逻辑独立性与物理独立性以及视图更新限制、DBA与系统分析员职责、数据库安全性控制常用方法等这些内容可帮助读者快速建立知识框架并对照常见考点查漏补缺。1. 数据库原理与应用不是背完就过的一门课面试后端岗位时我常看到一种人CRUD 写得飞起ORM 用得顺手但被追问一句“数据库原理”就卡壳。他们不是没学过而是把原理当成了名词解释——范式、ACID、B 树背得一字不差真让他们建一张符合规范的表或者解释线上一条慢 SQL 的成因立刻露馅。《数据库原理与应用第四版》这类教材真正该被拆开用的是那些“以不变应万变”的判断依据ER 模型决定建表结构索引结构决定 SQL 写法事务日志决定备份恢复策略。这篇文章按照设计、查询、事务、恢复这条主线走一遍把每个原理落成可执行的 SQL、命令和参数适合正在做数据库课程设计的同学也适合想系统性复习一遍原理的从业者。2. 数据库原理的建模落地从 ER 图到物理表2.1 先画 ER 图还是直接建表教材里反复强调的“需求分析—概念结构设计—逻辑结构设计—物理设计”四步法很多人当成流程摆设。我帮人评审过几次数据库课程设计的作业最常见的毛病恰恰是跳过了概念设计这一步同学拿到题目直接CREATE TABLE边做边加字段最后表之间要么冗余严重要么关联全靠 JOIN 硬凑连第三范式是什么都顾不上了。正常做法是先把实体和关系画出来再动手建表。以最经典的教学场景“学生选课”为例学生和课程是多对多关系中间必然要有一张选课表选课表里既存成绩也存选课时间这是“属性归附到关系”的典型应用。ER 图画完之后再用范式检查一遍有没有部分依赖——复合主键下只依赖其中一个键的字段要拆出去有没有传递依赖——比如通过学号能推出来的学院名称就不应该冗余在选课表里。到这里关系模型基本定型建表只是把它翻译成 SQL这比边写边想靠谱得多。2.2 北风数据库与课程设计的建表 SQL很多数据库原理实验课都喜欢拿北风数据库Northwind做练习它覆盖了订单、产品、客户这类典型业务关联。不过对课程设计来说三张表的小模型更有利于把原理讲清楚下面的建表语句就是按第三范式拆解出来的CREATE TABLE student ( student_id CHAR(8) NOT NULL COMMENT 学号定长编码, student_name VARCHAR(20) NOT NULL COMMENT 姓名, enroll_year SMALLINT NOT NULL COMMENT 入学年份, PRIMARY KEY (student_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE course ( course_id INT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 课程编号, course_name VARCHAR(50) NOT NULL, credits TINYINT UNSIGNED NOT NULL DEFAULT 0 COMMENT 学分, PRIMARY KEY (course_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE student_course ( student_id CHAR(8) NOT NULL, course_id INT UNSIGNED NOT NULL, score DECIMAL(5,1) DEFAULT NULL COMMENT 成绩允许为空表示未考试, select_time DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (student_id, course_id), CONSTRAINT fk_sc_student FOREIGN KEY (student_id) REFERENCES student(student_id), CONSTRAINT fk_sc_course FOREIGN KEY (course_id) REFERENCES course(course_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这段 SQL 里故意用了几个和“随手建表”不太一样的写法。学号用CHAR(8)而不是INT学号不参与算术运算定长字符串还能避免0001被转成1的隐性差错。入学年份用SMALLINT而不是DATETIME年份本来就是低基数的数值维度引入时间类型反而要处理时区问题。成绩用DECIMAL(5,1)而不是FLOAT/DOUBLE浮点存储会有 0.1 0.2 ! 0.3 这类精度误差教材里讲“完整性约束”时在数据类型层面就要排除这个隐患。选课表的复合主键(student_id, course_id)对应 ER 图里的多对多关系两个外键保证了引用完整性——缺了外键的库应用层漏写一个学号就会造出孤儿数据靠代码去补这种约束从来都是下策。2.3 字段类型与约束的选型要点字段类型选错是数据库 SQL 里最常见的低级事故我把高频场景整理成了下面的对照表也是面试题里翻来覆去问的知识点场景推荐类型不推荐及原因学号/工号/证件号CHAR / VARCHARBIGINT / INT丢失前导零且语义错误金额DECIMAL(10,2)FLOAT / DOUBLE二进制浮点有精度误差状态 / 枚举TINYINT 或 ENUMVARCHAR 存中文浪费空间且容易脏数据创建时间DATETIME / TIMESTAMPVARCHAR 存时间字符串无法走索引范围扫描大文本TEXT / MEDIUMTEXTVARCHAR(8000) 硬撑超出行长度限制选型有一条判断原则先想清楚这个字段将来要做什么操作再决定类型。要参与计算用数值类型且优先固定精度只要等值和排序用字符串类型没问题要按时间范围过滤就必须用时间类型否则索引优化器帮不了你。增删改查是数据库操作的基本功但建表时类型选对了后面所有增删改查都会顺畅得多类型选错后面写的每一条 SQL 都是在给当时偷的懒还债。3. 数据库原理的索引篇B 树、EXPLAIN 与 JOIN 优化3.1 为什么关系数据库默认用 B 树教材讲 B 树一定会提“矮胖”但这个“矮胖”只有和磁盘 IO 联系起来才有意义。InnoDB 默认页大小是 16KB一次磁盘 IO 能读进内存的节点越多查找一个键需要的 IO 次数就越少。B 树的非叶子节点不存数据一层节点能放上千个键三到四层就能支撑千万行数据这是二叉树望尘莫及的——二叉树深度动辄几十层每层一次随机 IO在机械盘上就是灾难。哈希索引当然也存在InnoDB 有自适应哈希索引来加速等值查找但这东西不是叶子节点串在一起的数据结构无法支持范围查询和排序。SQL 里最常见的 WHERE 条件恰好是BETWEEN、、这类范围扫描B 树叶子节点用双向链表串联天然适合这种访问模式。理解了这一点你就能想明白为什么对“性别”这种区分度极低的字段建索引收益很小索引要能快速缩小目标行集合低区分度字段一扫描就是半张表优化器会直接放弃索引走全表。这个判断依据在向量数据库、文档型数据库里同样适用只是索引换成了 HNSW 那套图结构本质还是“空间换时间、顺序换随机”的取舍。3.2 用 EXPLAIN 给慢 SQL 定位MySQL 里任何 SQL 性能疑问第一步都应该是看执行计划而不是凭感觉加索引。下面这条查询是课程设计里常见的“查 2023 年入学学生的选课成绩并按分数排序”EXPLAIN SELECT s.student_name, c.course_name, sc.score FROM student s JOIN student_course sc ON s.student_id sc.student_id JOIN course c ON sc.course_id c.course_id WHERE s.enroll_year 2023 ORDER BY sc.score DESC;执行计划里最值得关注的是type、key、rows和Extra四个字段。type出现ALL全表扫描或index完整索引扫描通常意味着设计有问题rows是优化器估算的扫描行数正常情况下它和真实数据量同量级数量越大代价越高Extra里出现Using temporary和Using filesort说明ORDER BY或GROUP BY没有吃到索引红利正在临时表里做排序。对上面这条 SQL典型问题在 JOIN 的驱动方向以enroll_year过滤后的 student 结果集作为驱动表如果建了联合索引(enroll_year, student_id)优化器大概率走索引扫描而不是ALL。执行计划输出的是优化器基于统计信息的估算所以数据量大变之后记得跑一下ANALYZE TABLE如果计划变了说明之前只是统计信息过期不是 SQL 本身的问题。3.3 JOIN 语义与索引失效的常见边界MySQL 数据库 JOIN 隐含的行文语义是数据库原理里“关系代数”的延伸也是面试题常客。INNER JOIN只保留两表匹配成功的行LEFT JOIN保留左表全部行右表无匹配时补NULL。很多人踩过的坑是统计左表行数时写了COUNT(a.id)结果因为ON条件里有 1:N 匹配行数翻了好几倍——这和教材里那句“连接操作会改变结果集的基数”完全呼应。索引失效则是另一类高频问题。对索引列做函数运算DATE(create_time) 2024-01-01、隐式类型转换字符串列和整数比较、前导模糊匹配LIKE %abc都会让优化器放弃索引。排查方法很机械把 WHERE 条件逐个还原成原始列比较再分别跑 EXPLAIN 确认type是否恢复到ref或range。下面是几个常见场景的对比WHERE 写法能不能用索引原因create_time 2024-01-01 AND create_time 2024-01-02能范围谓词B 树支持DATE(create_time) 2024-01-01不能索引列被函数包裹student_id 20230001列是 VARCHAR不能隐式类型转换破坏比较name LIKE 张%能前缀匹配还在索引范围内name LIKE %张不能前导模糊无法定位起始键(enroll_year, student_id)联合索引下WHERE student_id ...不能跳过了联合索引最左列4. 数据库原理的事务篇ACID、隔离级别与死锁排查4.1 WAL 日志先行是 ACID 的基石教材讲事务时反复强调“原子性、一致性、隔离性、持久性”但真正的实现基石是预写日志Write-Ahead Logging简称 WAL。InnoDB 的数据页先缓存在 buffer pool 里再异步刷盘而 redo log 会在事务提交时强制写盘。这个顺序不能颠倒先记日志、再改数据页宕机后靠 redo log 重放未完成的操作数据才不会丢。把 WAL 的逻辑推演到生产环境很多怪现象就解释得通了。比如连接池里会话数设得很大业务却莫名变慢常见原因是一条长事务把 redo log 撑满刷盘变成了同步等待又比如数据库同步工具消费 binlog 时位点一直追不上往往也是源库长事务导致 binlog 文件膨胀。理解“日志先行”之后再去调这类参数每一步都知道自己在干什么而不是随机试。4.2 隔离级别和锁的行为差异标准 SQL 定义了四个隔离级别但真正需要反复比较的是“可重复读”和“读已提交”这两个。它们在锁行为上差异明显MySQL 默认的可重复读需要用 next-key lock记录锁加间隙锁来防幻读锁的范围覆盖索引区间及其间隙读已提交不再引入间隙锁锁冲突更少。选哪个要看业务性质账务类业务对范围内数据的一致性要求高用可重复读高并发订单系统更在意吞吐常用读已提交降低锁等待。隔离级别脏读不可重复读幻读锁代价READ UNCOMMITTED可能可能可能最低READ COMMITTED否可能可能低REPEATABLE READMySQL 默认否否否next-key lock高SERIALIZABLE否否否最高这个表不用死记理解逻辑即可隔离级别越严锁的范围越宽并发度越低。生产环境常见的一个折中是“读已提交 应用层补偿”订单创建和库存扣减之间允许中间态短暂可见但最终通过对账保证一致。数据库并发锁的很多调优本质上都是在“隔离级别的严格程度”和“业务可接受的中间态”之间找平衡点。4.3 用两个会话复现死锁并看诊断信息数据库死锁不可能完全杜绝但对一个成熟的研发来说定位死锁是基本功。我常用两个 MySQL 会话模拟经典的交叉加锁会话 A 先更新订单表再更新明细表会话 B 反过来先更新明细表再更新订单表两者必然在某一刻互持对方需要的锁。-- 会话 A BEGIN; UPDATE orders SET amount amount 1 WHERE order_id 1; UPDATE order_detail SET quantity quantity 1 WHERE detail_id 2; COMMIT; -- 会话 B与 A 交替执行 BEGIN; UPDATE order_detail SET quantity quantity 1 WHERE detail_id 2; UPDATE orders SET amount amount 1 WHERE order_id 1; COMMIT;当两个会话交替执行到第二步时其中之一会收到Deadlock found when trying to get lock错误事务被回滚。这时先执行SHOW ENGINE INNODB STATUS在输出里找LATEST DETECTED DEADLOCK段里面会给出参与死锁的两个事务及其持有的锁资源直接把两条 SQL 摘出来分析。同时可以查information_schema.innodb_trx和sys.innodb_lock_waits找到当前正在等待锁的事务trx_query字段会显示实际语句这比翻应用日志要快得多。修复死锁有常见的三条路径让所有事务按同一顺序访问资源比如先订单后明细从根上消除交叉等待缩小事务范围把查询挪到事务外减少持锁时间把长事务拆成多个短事务。前两条属于设计层面的根治第三条只能算缓解。排查时别忘了看一下连接池配置连接有点多也会放大锁等待这属于数据库并发锁调优里容易忽略的环节。5. 数据库原理的恢复篇用一次备份恢复演练验证 RPO5.1 恢复能力必须靠演练验证而不是文档原理书里“故障恢复”一章讲的是恢复算法但工程上真正要回答的是两个指标RPO——最多丢多少数据RTO——多久能恢复服务。这两个数字没法靠脑补必须靠一次完整的备份恢复演练来验证。数据库同步工具和主从复制本质上也是围绕日志做文章理解了 WAL 之后再去看那些工具的配置会发现核心无非是“日志位点”和“幂等重放”两件事。5.2 一次备份与增量恢复的完整命令我用下面的命令组合完成一次演练全量备份、制造增量写入、把日志应用到新实例。全程没用图形界面工具全部命令操作可控性最强。# 步骤一全量备份逻辑备份 mysqldump -uroot -p --single-transaction --master-data2 \ --databases school /backup/school_full_$(date %F).sql # 步骤二模拟增量数据后导出 binlog 中的一小段 mysqlbinlog --start-datetime2024-01-01 00:00:00 \ --stop-datetime2024-01-01 00:10:00 \ --base64-outputDECODE-ROWS -v /var/lib/mysql/binlog.000012 \ /backup/inc_0010.sql # 步骤三在新实例上恢复 mysql -uroot -p /backup/school_full_2024-01-01.sql mysql -uroot -p /backup/inc_0010.sql关键参数说明--single-transaction在 InnoDB 下利用 MVCC 做一致性快照备份期间不锁业务表--master-data2会把 binlog 位点注释写到备份文件头部这是后续恢复增量日志的起点mysqlbinlog里的--base64-outputDECODE-ROWS配合-v把 ROW 事件转成可读 SQL恢复前能人工确认没有误改数据。5.3 恢复后的三个校验动作恢复完成后不要急着宣布成功先用COUNT(*)对比全量表行数再用MAX(update_time)确认增量数据已经应用最后抽样几条关键记录对比CHECKSUM TABLE的结果。三个校验全过了这次演练才算闭环。这套流程换到达梦数据库、人大金仓这类国产数据库上思路也一致——它们的备份工具和mysqldump参数名不同但“一致性快照 增量日志 位点”的铁三角没有变。原理学扎实了换数据库只是重新查一遍工具手册的事。本文还有配套的精品资源点击获取