2021-07-24

MySQL体系结构与存储引擎

• redo log 是物理日志,记录的是“在某个数据页上做了什么修改”；循环写，空间会使用完。
• binlog 是逻辑日志，记录的是这个语句的原始逻辑，比如“给 ID=2 这一行的 c 字段加 1 ”；追加写入，不会覆盖之前的内容。

模块一：高性能MySQL基础篇

1. 一条Select的执行轨迹

2. 一条Update的执行轨迹
update T set c=c+1 where ID=2

3.InnoDB存储引擎–MySQL5.6

• 3. 1 buffer pool
  (1).buffer pool文件决定了SQL的执行快慢，单机实例情况下一般为物理内存的50%~60%。
  (2).查看buffer pool的占用：show global status like ‘%buffer_pool_wait%’
• 3. 2 redo log
  循环复用的文件集件，负责记录所有对Buffer pool的物理修改日志，影响数据库的处理能力

4.ARIES 三原则

5.多版本控制–MVCC
  多版本控制也叫作 MVCC，是指在数据库中，为了实现高并发的数据访问，对数据进行多版本处理，并通过事务的可见性来保证事务能看到自己应该看到的数据版本。读不加锁。读操作可以分为两类:

• 快照读（Snapshot Read）读取的是记录的可见版本（有可能是历史版
  本），不用加锁。
• 当前读 （Current Read）读取的是记录的最新版本，并且当前读返回的记录，都会加锁，保证其他事务不会再并发修改这条记录

注意：MVCC 只在 Read Commited 和 Repeatable Read 两种隔离级别下工作。

如何区分快照读和当前读呢？ 可以简单的理解为：

• 快照读：简单的 select 操作，属于快照读，不需要加锁。
• 当前读：特殊的读操作，插入/更新/删除操作，属于当前读，需要加锁。

那个多版本是如何生成的呢？
  每一次对数据库的修改，都会在 Undo 日志中记录当前修改记录的事务号及修改前数据状态的存储地址（即 ROLL_PTR），以便在必要的时候可以回滚到老的数据版本。例如，一个读事务查询到当前记录，而最新的事务还未提交，根据原子性，读事务看不到最新数据，但可以去回滚段中找到老版本的数据，这样就生成了多个版本。
6.MySQL中锁的分类

- InnoDB行锁实行算法

• Record Lock 锁：单个行记录的锁（锁数据，不锁 Gap）。
• Gap Lock 锁：间隙锁，锁定一个范围，不包括记录本身（不锁数据，仅仅锁数据前面的Gap）。
• Next-key Lock 锁：同时锁住数据，并且锁住数据前面的 Gap。

- InnDB产生死锁的四个条件

• 互斥条件：一个资源每次只能被一个进程使用；
• 请求与保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放；
• 不剥夺条件：进程已获得的资源，在没使用完之前，不能强行剥夺；
• 循环等待条件：多个进程之间形成的一种互相循环等待资源的关系。

- 如何避免死锁的产生

模块二：互联网高性能MySQL最佳实践

1. 范式

• 第一范式
    第一范式无重复的列，表中的每一列都是拆分的基本数据项，即列不能够再拆分成其他几列，强调的是列的原子性
    如果在实际场景中，一个联系人有家庭电话和公司电话，那么以“姓名、性别、电话”为表头的表结构就没有达到 1NF。要符合 1NF 我们只需把电话列拆分，让表头变为姓名、性别、家庭电话、公司电话即可。
• 第二范式
    第二范式属性完全依赖于主键，首先要满足它符合 1NF，另外还需要包含两部分内容：
  • 表必须有一个主键；
  • 没有包含在主键中的列必须完全依赖于主键，而不能只依赖于主键的一部分。即要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性。
• 第三范式
    第三范式属性不传递依赖于其他非主属性，首先需要满足 2NF，另外非主键列必须直接依赖于主键，不能存在传递依赖。即不能存在：非主键列 A 依赖于非主键列 B，非主键列 B 依赖于主键的情况。
  
  2. 命名规范
  
  
  
  
  
  
  3. 索引
  • 聚簇索引
     聚簇索引是一种数据存储方式，它表示表中的数据按照主键顺序存储，是索引组织表。InnoDB 的聚簇索引就是按照主键顺序构建 B+Tree，B+Tree 的叶子节点就是行记录，数据行和主键值紧凑地存储在一起。 这也意味着 InnoDB 的主键索引就是数据表本身，它按主键顺序存放了整张表的数据。
     而 InnoDB 辅助索引（也叫作二级索引）只是根据索引列构建 B+Tree，但在 B+Tree 的每一行都存了主键信息，加速回表操作。

4. 查询性能

- badSQL案例

5. 提高单库性能

-CPU

- 内存

- 磁盘

• MySQL参数优化
  
  
  

6. MySQL主从复制原理

模块三：MySQL高可用

1. MTBF 和 MTTR

• MTBF
   MTBF（全称是Mean Time Between Failures，即平均故障间隔），是指系统在运行期间的平均连续无故障时间，提升 MTBF 就意味着减少故障出现的次数，加大系统正常运行的服务时长。
   $最近一次故障时间downtime-上一次故障修复时的时间uptime$
  

• MTBF
    MTTR（全称是Mean Time To Recovery，也就是平均修复时间），是指系统由故障状态转为正常运行状态所需修复时间的平均值。降低 MTTR 就意味着加速故障恢复的速度，例如故障在秒级恢复。

2. 服务器监控要点

3. 常用监控系统

模块四：可扩展MySQL

1. 扩展的基本方法有哪些

2. 基于分布式事务的数据库

2. 1 TiDB

• TiDBServers
   TiDB Server 负责接收 SQL 请求，处理 SQL 相关的逻辑，并通过 PD 找到存储计算所需数据的 TiKV 地址，与 TiKV 交互获取数据，最终返回结果。 TiDB Server 是无状态的，其本身并不存储数据，只负责计算，可以无限水平扩展，可以通过负载均衡组件（如 LVS、HAProxy 或 F5）对外提供统一的接入地址。
• PDServer
   Placement Driver （简称 PD）是整个集群的管理模块，其主要工作有三个： 一是存储集群的元信息（某个 Key 存储在哪个 TiKV 节点）；二是对 TiKV 集群进行调度和负载均衡（如数据的迁移、Raft group leader 的迁移等）；三是分配全局唯一且递增的事务 ID。
   PD 是一个集群，需要部署奇数个节点，一般线上推荐至少部署 3 个节点。
• TiKV Server
   TiKV Server 负责存储数据，从外部看 TiKV 是一个分布式的提供事务的 Key-Value 存储引擎。存储数据的基本单位是 Region，每个 Region 负责存储一个 Key Range （从 StartKey 到EndKey 的左闭右开区间）的数据，每个 TiKV 节点会负责多个 Region 。TiKV 使用 Raft 协议做复制，保持数据的一致性和容灾。副本以 Region 为单位进行管理，不同节点上的多个 Region 构成一个 RaftGroup，互为副本。数据在多个 TiKV 之间的负载均衡由 PD 调度，这里也是以 Region 为单位进行调度。

2. 2 ArkDB

• ArkDB Server
   ArkDB Server 为数据库接入层，负责响应客户端链接和权限验证，接收并处理 SQL 请求，包含连接管理、权限验证、分析器、优化器和执行器等，所以也叫计算节点。ArkDB Server 为无状态节点，其自身不存储数据，可以快速无限水平扩展，各个计算节点之间通过物理日志同步，同时通过操作 ArkDB Server 节点，实现整个数据库机器的高可用切换。在 ArkDB Server 层处理 SQL 请求的时候，需要分配合适的内存和 CPU 资源，对存储则无要求，可以做针对性的硬件优化。
• ArkDB Engine
   ArkDB Engine 负责数据存储和读取，底层采用分布式存储。每个数据存储单位默认存储 3 副本，副本间的数据保持强一致性和容灾。ArkDB Engine 负责存储数据并实现数据共享。上层ArkDB Server 节点访问 ArkDB Engine 同一份数据。ArkDB Engine 支持根据业务访问策略对数据存储分级，用户可以根据预算、性能指标、容量请求、访问场景按需使用不同的存储硬件，同时针对闪存卡进行软硬件结合优化。

模块五：海量MySQL实战