这是我参与「第五届青训营」伴学笔记创作活动的第 16 天
课程概述
RDBMS（关系型数据库）是目前使用最为广泛的数据库之一，同时也是整个信息化时代的基石。本节课程通过生活中常见的场景向大家介绍RDBMS的作用、发展历程及其核心技术，最后以字节为例，展示了RDBMS的企业级实践。本节课程主要包含以下内容：
- 经典案例
- 发展历史
- 关键技术
- 企业实践
课前材料
RDBMS有相关的数据和材料都非常多，这里主要给大家提供几篇经典论文，从经典的论文中，能够更有效的帮助大家理解RDBMS。
- A Relational Model of Data for Large Shared Data Banks
这篇论文是RDBMS的奠基之作，由RDBMS之父E.F.Codd博士于1970年发表。在这篇论文中，E.F.Codd首次提出了用于管理数据的关系模型，并将数据独立于硬件来存储，用户使用一个非过程语言来访问数据。
- Readings in Database Systems(Fifth Edition)
这本书被称为数据库领域的“红宝书”，由著名的图灵奖获得者，数据库领域专家，Michael Stonebraker撰写。其中介绍了数据库的基本概念，传统的RDBMS以及新的数据库架构等等，是一本非常棒的数据库领域入门文章。
课程详情
经典案例
通过抖音红包雨的案例，介绍 RDBMS 中 ACID 的概念：
- 原子性(Atomicity)：事务是一个不可再分割的工作单元，事务中的操作要么都发生，要么都不发生。
- 一致性(Consistency)：数据库事务不能破坏关系数据的完整性以及业务逻辑上的一致性。
- 隔离性(Isolation)：多个事务并发访问时，事务之间是隔离的，一个事务不应该影响其它事务运行效果。
- 持久性(Durability)：在事务完成以后，该事务所对数据库所做的更改便持久的保存在数据库之中，并不会被回滚。
发展历史
数据库发展最初过程中，诞生过3种数据模型，最终关系型模型成为了应用最为广泛的数据库模型。
- 网状模型：用有向图表示实体和实体之间的联系的数据结构模型称为网状数据模型。
- 层次模型：层次数据模型是用树状<层次>结构来组织数据的数据模型。
- 关系模型：使用表格表示实体和实体之间关系的数据模型称之为关系数据模型。
| 网状模型 | 层次模型 | 关系模型 | |
|---|---|---|---|
| 优势 | 能直接描述现实世界 存取效率较高 | 结构简单 查询效率高 可以提供较好的完整性支持 | 实体及实体间的的联系都通过二维表结构表示 可以方便的表示M:N关系 数据访问路径对用户透明 |
| 劣势 | 结构复杂 用户不易使用 访问程序设计复杂 | 无法表示M:N的关系 插入、删除限制多 遍历子节点必须经过父节点 访问程序设计复杂 | 关联查询效率不够高 关系必须规范化 |
关键技术
SQL 执行流程
在SQL执行过程中，需要经历SQL引擎、存储引擎、以及事务引擎等模块。而其中SQL引擎又分为Parser、Optimizer、Executor几个部分：
SQL引擎
查询解析：SQL 语言接近自然语言，入门容易。但是各种关键字、操作符组合起来，可以表达丰富的语意。因此想要处理SQL命令，首先将文本解析成结构化数据，也就是抽象语法树 （AST）。
查询优化：SQL 是一门表意的语言，只是说『要做什么』，而不说『怎么做』。所以需要一些复杂的逻辑选择『如何拿数据』，也就是选择一个好的查询计划。优化器的作用根据AST优化产生最优执行计划（Plan Tree）。
查询执行：根据查询计划，完成数据读取、处理、写入等操作。
事务引擎：处理事务一致性、并发、读写隔离等
存储引擎：内存中的数据缓存区、数据文件、日志文件
SQL 引擎
SQL引擎包括了：
- Paser：经过词法分析、语法分析生成语法树，然后对语法树进行合法性校验。
所有的代码在执行之前，都存在一个解析编译的过程，差异点无非在于是静态解析编译还是动态的。
SQL语言也类似，在SQL查询执行前的第一步就是查询解析。
词法分析：将一条SQL语句对应的字符串分割为一个个token，这些token可以简单分类。
语法分析：把词法分析的结果转为语法树。根据tocken序列匹配不同的语法规则，比如这里匹配的是update语法规则，类似的还有insert、delete、select、create、drop等等语法规则。根据语法规则匹配SQL语句中的关键字，最终输出一个结构化的数据结构。
语义分析：对语法树中的信息进行合法性校验。
- Optimizer：根据Parser产生的语法树，根据规则或者代价产生执行计划树。
到达一个目的地，有不同的路线，选择不同的路线有不同的代价。这里的代价可能是时间，也可能是路程。比如我们赶时间的时候，就会选择时间最短的。如果时间没那么赶，那么我们可能选择路程最短的。因为这样省油啊，毕竟现在油价这么高。
对于数据库也是这样，一个查询有不同的执行方案。
那对于数据库而言，什么是一条SQL执行的代价呢？
其实，对于用户只能感知到查询时间这个代价，底层用了多少资源他是不在乎的。但是在并发的情况下，就得考虑资源消耗了，这个用户的查询占用的资源多了，其他用户的资源就少了。所以资源也是必须考虑的一点。
对于InnoDB 存储引擎来说，全表扫描的意思就是把聚簇索引中的记录都依次和给定的搜索条件做一下比较，把符合搜索条件的记录加入到结果集，所以需要将聚簇索引对应的页面加载到内存中，然后再检测记录是否符合搜索条件。
对于使用二级索引 + 回表方式的查询，设计MySQL 的大叔计算这种查询的成本依赖两个方面的数据：范围区间数量，需要回表数据量
- Executor：根据计划树进行执行，常见的执行方式是火山模型。
存储引擎
存储引擎负责了数据的底层存储、管理和访问工作。各大RDBMS存储引擎的设计都有不少的差异，这里选择MySQL的InnoDB存储引擎来向大家做一个介绍：
- Buffer Pool：存储引擎位于内存中的重要结构，用于缓存数据，减少磁盘IO的开销。
- Page：数据存储的最基本单位，一般为16KB。
- B+u Tree：InnoDB中最常用的索引结构。
事务引擎
事务引擎实现了数据库的ACID能力，这里还是以MySQL的InnoDB为例来介绍数据库内部是通过哪些技术来实现ACID：
- Atomicity：InnoDB中通过undo日志实现了数据库的原子性，通过Undo Log，数据库可以回滚到事务开始的状态；
- Isolation：通过Undo Log实现MVCC（多版本并发控制），降低读写冲突。
- Durability：通过Redo Log（一种WAL实现方式）来保证事务在提交后一定能持久化到磁盘中。
- Consistency：一致性本质上是一种业务层的限制。
企业实践
字节中是国内数据规模最大的互联网公司之一，公司内部有成千上万套RDBMS系统。这一章节还是以红包雨为案例，展示了字节是如何解决大流量、流量突增、高可靠等问题的。
课后大作业
- WAL 日志到底是如何保证数据的持久化，宕机后数据不丢失的？相比于其他方案，WAL 日志都有什么优势？
- 除了 Undo Log 之外，是否还有其他方案可以实现 MVCC？
- 基于代价的优化器一般需要考虑哪些代价？
- 执行器的执行模型，除了本课中提到的火山模型是否还有其他模型？相比于火山模型有什么优劣势？
- InnoDB 的 B+ Tree 是怎么实现的？
- InnoDB 的 buffer pool 是怎么实现页面管理和淘汰的？
