这是我参与「第五届青训营 」伴学笔记创作活动的第 17 天
一、本堂课重点内容：
- SQL 执行流程
- SQL 引擎
- 存储引擎
- 事务引擎
二、详细知识点介绍：
事务
事务(Transaction)：是由一组SQL语句组成的一个程序执行单元(Unit)，它需要满足ACID特性
ACID
-
Atomicity：InnoDB中通过undo日志实现了数据库的原子性，通过Undo Log，数据库可以回滚到事务开始的状态；
-
Isolation：通过Undo Log实现MVCC（多版本并发控制），降低读写冲突。
-
Durability：通过Redo Log（一种WAL实现方式）来保证事务在提交后一定能持久化到磁盘中。
-
Consistency：一致性本质上是一种业务层的限制。
发展历史
数据库发展最初过程中，诞生过3种数据模型，最终关系型模型成为了应用最为广泛的数据库模型。
- 网状模型：用有向图表示实体和实体之间的联系的数据结构模型称为网状数据模型。
- 层次模型：层次数据模型是用树状<层次>结构来组织数据的数据模型。
- 关系模型：使用表格表示实体和实体之间关系的数据模型称之为关系数据模型。
| 网状模型 | 层次模型 | 关系模型 | |
|---|---|---|---|
| 优势 | 能直接描述现实世界 存取效率较高 | 结构简单 查询效率高 可以提供较好的完整性支持 | 实体及实体间的的联系都通过二维表结构表示 可以方便的表示M:N关系 数据访问路径对用户透明 |
| 劣势 | 结构复杂 用户不易使用 访问程序设计复杂 | 无法表示M:N的关系 插入、删除限制多 遍历子节点必须经过父节点 访问程序设计复杂 | 关联查询效率不够高 关系必须规范化 |
SQL语言
- 语法风格接近自然语言；
- 高度非过程化；
- 面向集合的操作方式；
- 语言简洁，易学易用。
关键技术
SQL引擎
- 解析器(Parser)一般为词法分析（Lexical analysis）、语法分析（Syntax analysis）、语义分析（Semantic analyzer）等步骤
- 经过词法分析、语法分析生成语法树，然后对语法树进行合法性校验。
- Optimizer：根据Parser产生的语法树，根据规则或者代价产生执行计划树
- 基于规则的优化(RBO Rule Base Optimizer)
- 基于代价的优化(CBO Cost Base Optimizer)
- Executor：根据计划树进行执行，常见的执行方式是火山模型。
- 向量化
- 编译执行
存储引擎 - InnoDB
In-Memory
- Buffer Pool
- Change Buffer
- Adaptive Hash Index
- Log Buffer
On-Disk
- System Tablespace(ibdata1)
- General Tablespaces(xxx.ibd)
- Undo Tablespaces(xxx.ibu)
- Temporary Tablespaces(xxx.ibt)
- Redo Log(ib_logfileN)
存储引擎负责了数据的底层存储、管理和访问工作。各大RDBMS存储引擎的设计都有不少的差异，这里选择MySQL的InnoDB存储引擎来向大家做一个介绍：
- Buffer Pool：存储引擎位于内存中的重要结构，用于缓存数据，减少磁盘IO的开销。
- Page：数据存储的最基本单位，一般为16KB。
- B+u Tree：InnoDB中最常用的索引结构。
事务引擎
事务引擎实现了数据库的ACID能力，这里还是以MySQL的InnoDB为例来介绍数据库内部是通过哪些技术来实现ACID：
- Atomicity 与 Undo Log：InnoDB中通过undo日志实现了数据库的原子性，通过Undo Log，数据库可以回滚到事务开始的状态；
- Isolation 与 锁：通过Undo Log实现MVCC（多版本并发控制），降低读写冲突。
- Durability：通过Redo Log（一种WAL实现方式）来保证事务在提交后一定能持久化到磁盘中。
- Consistency：一致性本质上是一种业务层的限制。
三、实践练习例子：
春节红包雨挑战
大流量 - Sharding
问题背景
- 单节点写容易成为瓶颈
- 单机数据容量上限
解决方案
- 业务数据进行水平拆分
- 代理层进行分片路由
实施效果
- 数据库写入性能线性拓展
- 数据库容量线性拓展
流量突增 - 扩容
问题背景
- 活动流量上涨
- 集群性能不满足要求
解决方案
- 利用DB物理节点数量
- 利用影子表进行压测
实施效果
- 数据库集群提供更高的吞吐
- 保证集群可以承担预期流量
流量突增 - 代理连接池
问题背景
- 突增流量导致大量建联
- 大量建联导致负载变大，延时上升
解决方案
- 业务侧预热连接池
- 代理侧预热连接池
- 代理侧支持连接队列
实施效果
- 避免 DB 被突增流量打死
- 避免代理和 DB 被大量建联打死
稳定性&可靠性 - 3AZ高可用
三机房部署
- 机房级别容灾
- 机房级别流量调度
proxy
- 读写分离，分库分表
- 限流，流量调度
监控报警
HA
- High Availability
- 实时监控DB运行状态
- 宕机快速切换
四、课后个人总结：
一、讲师讲的很好，对于案例的讲解十分到位。
二、通过SQL的一生去深层次理解SQL的执行，很有意思。
三、对实践环节的知识仍需加强
