这是我参与「第三届青训营 -后端场」笔记创作活动的第5篇笔记

深入理解RDBMS，关系型数据库管理系统。老师通过一些实际案例出发，讲解关系型数据库的核心技术，帮助大家理解。

经典案例

抖音红包雨
抖音账户扣除一个小目标
羊老师账号加上一个小目标
SQL实现：
UPDATE account_table SET balance = balance - '小目标' WHERE name =' 抖音';
UPDATE account_table SET balance = balance + '小目标' WHERE name = '羊老师';

RDBMS 事务ACID

事务（Transaction）：是由一组SQL语句组成的一个程序执行单元（Unit），需要满足ACID特性。

·原子性(Atomicity):事务是一个不可再分割的工作单元，事务中的操作要么都发生，要么都不发生。
·一致性(Consistency):数据库事务不能破坏关系数据的完整性以及业务逻辑上的一致性。
·隔离性(solation):多个事务并发访问时，事务之间是隔离的，一个事务不应该影响其它事务运行效果。
·持久性(urability):在事务完成以后，该事务所对数据库所作的更改便持久的保存在数据库之中，并不会被回滚。

红包雨及ACID：

1、抖音账号扣除一个亿之后，假设服务器挂了，来不及给羊老师账号加上；

抖音血亏，羊老师不赚
原子性：两个操作要么同时成功，要么同时失败，不存在中间状态的！

2、假设抖音账号只有0.5个亿，但是扣除一个亿的操作成功了

哈哈哈
银行血亏，并决定把抖音账号封了
一致性：每个操作必须是合法的，账号信息应该从一个有效状态变为另一个有效状态

3、羊老师从抖音抢了一个亿，又从头条抢了一个亿，初始为0，两个转账同时进行，更新羊老师账户余额，最终得到一个亿

羊老师赚了又没完全赚嘿
隔离性：两个操作在对同一个账户并发进行操作时，应该是互不影响的，表现的像是串行操作

4、抖音账户扣了一个亿，然后在羊老师账户上加上，但是都还没写到磁盘上，服务器挂了

双方不变，羊老师到手的一个亿没了
持久性：操作更新成功之后，更新的结果应该永久性的保留下来，而不会因为宕机等问题丢失

红包雨与高并发：

5、全国14亿人，假设10亿人同时开抢红包，每秒处理一个请求，那需要31年才能完成。。。

如果每秒处理1000w请求，那么只需要1min40s

红包雨与高可靠

6、假设除夕晚上大家正在抖音薅羊毛，77但是服务器挂了，程序员花了一个小时修复，此时《难忘今宵》都唱完了。。。。

服务器一定是要可靠稳定的！

发展历史

前DBMS时代

- 人工管理：结绳记事、账本、打孔机
- 文件系统：1950s，现代计算机雏形基本出现。1956年IBM发布了第一个磁盘驱动器-Model 305 RAMAC，从此数据存储进入磁盘时代，数据管理直接通过文件系统实现（记事本）

DBMS时代

1960s，传统的文件系统不能满足让人们的需要，数据库管理系统应运而生
DBMS：按照某种数据模型来组织、存储和管理数据的仓库，可以分为三类：网状模型、层次模型、关系模型

DBMS数据模型

SQL(Structured Query Language)语言

语语法风格接近自然语言;
高度非过程化;
面向集合的操作方式;
语言简洁，易学易用。

关键技术

一条SQL的一生

发展路线： SQL引擎：

- Parser：要处理SQL，首先要将文本解析成结构化数据，也就是抽象语法树（AST）
- Optimizer：SQL只告诉你要做什么，没有说怎么做。所以需要一些复杂的逻辑选择如何拿数据，需要去选择一个好的查询计划。优化器的作用是根据优化产生最优执行计划（Plan Tree）
- Executor：根据查询计划，完成数据读取、处理、写入等操作

事务引擎：处理事务一致性、并发、读写隔离等

存储引擎：内存中的数据缓存区、数据文件、日志文件

SQL引擎-Parase

分为词法分析、语法分析、语义分析等步骤
- 词法分析：将一条SQL语句对应的字符串分割为一个个token
- 语法分析：将上述结果转为语法树。根据token序列匹配不同的语法规则（update、insert、create等等），根据语法规则匹配SQL语句中的关键字，最终输出一个结构化饿数据结构。
- 语义分析：对语法树中的信息进行合法性校验。

SQL引擎-Optimizer

为什么需要一个优化器呢？
地图匹配路线的时候也会给出几个不同的选项，供用户去选择当前符合其预期的路线

基于规则的优化（RBO Rule Base Optimizer）

例如红绿灯少，就是规则

基于代价的优化（CBO Cost Base Optimizer）

什么是代价？时间、IO、CPU、NET、MEM
路线选择时也会有不同的代价：时间、路程等等

SQL引擎-Executor

火山模型（用的多）

基础是Plan Tree
调用关系是由根到叶
数据流是从叶到根

向量化模型

更适合于大批量数据处理，对于很多单行数据处理并没有优势；往往搭配列式存储使用

编译执行模型

存储引擎-InnoDB

以MySQL中InnoDB为例进行讲解

存储引擎-Buffer Pool

当buffer pool里的页面都被使用之后，再需要换存其他页面怎么办===>淘汰已有的页面

淘汰规则：最近一段时间最少被访问过的缓存页，LRU 普通LRU存在的缺陷：考虑需要扫描100g的表，而buffer pool只有1g，这样会因为全表扫描的数据量大，需要淘汰的缓存页太多，导致很有可能淘汰频繁使用到的缓存页

MySQL的改进：对数据进行冷热分离，将LRU链表分成两部分，一部分存冷数据（刚从磁盘读进来的数据），另一部分存储热数据（经常被访问到的数据）。当从磁盘读取到数据页后，会先将其放到冷数据区的头部，如果这些缓存页在1秒之后被访问，就会移动到热数据的头部，如果是1秒内被访问，则不会移动，仍处于冷数据区。淘汰时先淘汰冷数据区。

存储引擎-Page

存储引擎-B+ Tree

事务引擎-Atomicity与Undo log

事务是具有原子性的，不会停留在事务半中间的状态；那么事务在执行过程中发生错误，就要恢复到事务开始前的状态。
undo log是逻辑日志，记录饿是数据的增量变化，作用是保证事务的原子性和并发控制。可以用于事务回滚语句提供多版本机制（MVCC）、解决读写冲突和一致性读的问题

事务引擎-Isolation与锁

lsolation(隔离性)︰数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。
lsolation(隔离性)︰数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。
如果多个并发事务访问同一行记录，就需要锁机制来保证了。
读写是否冲突?读写互不阻塞，MVCC机制。

事务引擎-Isolation与MVCC

 脏读：事务还没提交之前，对数据做的修改不应该被其他人看到！！！

事务引擎-Durability与Redo log

持久化:事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。
WAL(Write-ahead logging):redo log是物理日志，记录的是页面变化，它的作用是保证事务持久化。如果数据写入磁盘前发生故障，重启MySQL后会根据redo log重做。
WAL优点：只记录增量变化，没有写放大；Append only，没有随机IO

RDBMS | 青训营笔记