clear old record

This commit is contained in:
Lostecho
2023-09-10 10:50:53 +08:00
commit 1cd5bb460f
283 changed files with 68653 additions and 0 deletions

View File

@@ -0,0 +1,125 @@
## MySQL 逻辑架构
![[Pasted image 20230708181100.png]]
### 连接管理与安全性
默认情况下,每个客户端连接在服务器进程中拥有一个线程,服务器维护了一个缓冲区,用于存放已就绪的线程
当客户端连接时,服务器需要对其进行身份验证,基于用户名,发起主机名和密码,连接成功后验证器权限
### 优化与执行
解析查询以创建内部数据结构,然后对其进行优化,包括重写查询,决定表的读取顺序,选择何时的索引
## 并发控制
### 读写锁
[[共享锁]]和[[排他锁]]
资源上的读锁是共享的,多个客户端可以同时读取一个资源而互不干扰,
写锁是排他的,一个写锁即会阻塞读锁也会阻塞其它的写锁,只有这样才能保证特定的时间点只有一个客户端执行写入,防止其它客户端读取正在写入的资源
锁的粒度
[[表锁]]
MySQL 中最基本也是开销最小的锁策略,锁定整张表
[[行级锁]]
可以最大程度地支持并发处理,也带来了最大的锁开销,锁定某一行
## 事务
### ACID
[[原子性]]
一个事物必须被视为一个不可分割的工作单元,整个事务中的所有操作要么全部提交成功,要么全部回滚失败
[[一致性]]
数据库总是从一个一致性状态转换到下一个一致性状态
[[隔离性]]
一个事务所做的修改在最终提交前,对其它事务是不可见的
[[持久性]]
一旦提交,事务所做的修改就会被永久保存到数据库中
### 隔离级别
[[READ UNCOMMITTED]] 未提交读
在事务中可以查看其他事务中还没有提交的修改,读取未提交的数据,也称为脏读
[[READ COMMITTED]] 提交读
一个事物可以看到其它事务在它开始之后提交的修改,但在该事务提交前,其所做的任何修改对其他事务都是不可见的,依然允许不可重复读
[[REPEATABLE READ]] 可重复读
保证了在同一个事务中多次读取相同行数据的结果是一样的
[[SERIALIZABLE]] 可串行化
强制事务按序执行
### 死锁
指两个或多个事务相互持有和请求相同资源上的锁,产生了循环依赖
### 事务日志
存储引擎秩序更改内存中的数据副本,不用修改磁盘中的表,然后把更改的记录写入事务日志中,事务日志会持久化保存到硬盘上
### MySQL 中的事务
AUTOCOMMIT
默认情况下,单个 INSERT、UPDATE、DELETE 语句会被隐式包装到一个事务中执行并在成功后提交,
通过禁用该模式,可以在事务中执行一系列语句,并在结束时执行 COMMIT 或 ROLLBACK
MySQL 事务是由下层的存储引擎实现的,在同一个事务中,混合使用多种存储引擎是不可靠的
> 最好不要在应用程序中混合使用存储引擎。失败的事务可能导致不一致的结果,因为某些部分可以回滚,而其他部分不能回滚
隐式锁定和显示锁定
InnoDB 使用两阶段锁定协议,事务执行期间,随时都可以获得锁,但是锁只有在提交和回滚后才会释放,并且所有的锁会同时释放
> LOCK TABLES 命令和事务之间的交互非常复杂,并且在一些服务器版本中存在意想不到的行为。因此,本书建议,除了在禁用 AUTOCOMMIT 的事务中可以使用之外,其他任何时候都不要显式地执行 LOCK TABLES不管使用的是什么存储引擎
## 多版本并发控制
[[MMVC]] 多版本并发控制
MVCC 仅适用于 REPEATABLE READ 和 READ COMMITTED 隔离级别
## 复制
源节点为每个副本提供一个线程,该线程作为复制客户端登录,写入发生时会被唤醒,发送新数据
## 数据文件结构
表的元数据重新设计为一种数据字典,包含在表的 ibd 文件中,操作期间引入了字典对象缓存
## InnoDB 引擎
默认事务型存储引擎,为处理大量短期事务而设计的
> 最佳实践是使用 InnoDB 存储引擎作为所有应用程序的默认引擎。在好几个大版本之前MySQL 已经将 InnoDB 作为默认引擎,这让事情变得简单了
使用 MMVC 来实现高并发性,实现了 4 个标准隔离级别
基于聚簇索引构建的,提供了非常快的主键查找
JSON 文档支持
删除了基于文件的表元数据存储
引入了原子数据定义更改

View File

@@ -0,0 +1,2 @@
什么是合规性
建立合规控制体系

View File

@@ -0,0 +1,51 @@
## Performance Scheme 介绍
[[程序插桩]] instrument
在 MySQL 代码中插入探测代码,以获取我们想了解的数据
[[消费者表]] Consumer
存储关于程序插桩代码的表
### 插桩元件
performance_schema 中setup_instrument 表包含所有支持插桩的列表
- statement/sql/select
- wait/synch/mutex/innodb/autoinc_mutex
## 配置
### 启用或禁用插桩
- 使用 setup_instruments 表
- 调用 sys schema 中的 ps_setup_enable_instrument 存储过程
- 使用 performance-schema-instrumet 启动参数
### 启用或禁用消费者表
- 使用 Performance Schema 中的 setup_consumers 表
- 调用 sys schema 中的 ps_setup_enable_condumer 或 ps_setup_disable_consuper 存储过程
- 使用 performance-schema-consumer 启动参数
## 使用 Performance Scheme
检查 SQL 语句
检查读写性能
检查元数据锁
检查内存使用情况
检查变量
- 服务器变量
- 状态变量
- 用户变量
检查最常见的错误
检查 Performance Schema 自身

View File

@@ -0,0 +1,3 @@
选择优化的数据类型
MySQL schema 设计中的陷阱
schema 管理

View File

@@ -0,0 +1,2 @@
托管 MySQL
虚拟机上的 MySQL

View File

@@ -0,0 +1,43 @@
## MySQL 的配置是如何工作的
从命令行参数和配置文件中的设置项获取配置信息
> 需要永久使用的任何设置都应该写入全局配置文件,而不是在命令行中指定。否则会有风险,可能会在没有指定命令行选项的情况下意外启动服务器。将所有配置文件保存在一个地方也是一个好主意,这样可以方便地检查它们
配置的作用域,服务器范围(全局作用于),每个连接(会话作用域)
> 如果在服务器运行时设置变量的全局值,则当前会话和其他现有会话的值将不受影响。如果客户端依赖数据库长连接,请务必记住这一点。这是因为在创建连接时,会话值是从全局值初始化的。在每次更改后应该检查 SHOW GLOBAL VARIABLES 的输出,以确保其达到预期效果
## 什么不该做
按比例调优
## 创建MySQL配置文件
## 配置内存使用
每个连接打内存需求
为操作系统保留内存
InnoDB 缓冲池
线程缓存
## 配置 MySQL 的 I/O 行为
InnoDB 事务日志
日志缓冲区
> 改变 InnoDB 执行 I/O 操作的方式会极大地影响性能,所以在改变任何东西之前,一定要理解你在做什么
InnoDB 表空间
## 配置 MySQL 并发
## 安全设置
## 高级 InnoDB 设置

View File

@@ -0,0 +1,3 @@
索引基础
高性能的索引策略
维护索引和表

View File

@@ -0,0 +1,47 @@
### 可靠性对 DBA 团队的影响
### 定义服务水平目标
[[服务水平指标]] SLI
[[服务水平目标]] SLO
[[服务水平协议]] SLA
### 监控解决方案
**商业选项**
SolarWinds
**开源选项**
PerconaPMM, Performance Schema
> 连接风暴是指在生产系统中,应用程序层感知到查询延迟增加,并通过打开更多到数据库层的连接进行响应的情况。这可能会导致数据库负载显著增加,因为它要处理大量涌入的新连接,这会占用执行查询请求的资源。连接风暴可能导致 max_connections 中的可用连接突然减少,并增加数据库可用性的风险
> 设置复制延迟告警需要谨慎。对于复制延迟,可立即采取行动的补救措施并不总是可行的。另外,假如你没有从副本读取数据,考虑一下监控系统将复制延迟告警发送给某人是否会过于激进。告警,尤其是非工作时间的告警,对于接收人来说应该是需要立即采取行动的
功能分片(Functional sharding)是指将服务于特定业务功能的特定表分割到一个专用的集群中,以便单独管理该数据集的正常运行时间、性能甚至访问控制
水平分片(Horizontal sharding)是指当数据集的大小超过了可以在单个集群中可靠地提供服务的规模时,将它拆分为多个集群,并从多个节点提供数据,这依赖于某种查找机制来定位所需的数据子集
### 度量长期性能
了解业务节奏
有效地跟踪指标
- 为未来的容量做规划
- 预见何时需要重大改进,何时增量修改就够了
- 为运行基础架构增加的成本做规划
使用性能监控工具检查性能
对平均值说不
与百分位为友
长保留期和性能

View File

@@ -0,0 +1,7 @@
为什么要备份
定义恢复需求
设计 MySQL 备份方案
管理和备份二进制日志
备份和恢复工具
备份数据
从备份中恢复数据

View File

@@ -0,0 +1,6 @@
复制概述
复制原理
复制切换
复制拓扑
复制管理和维护
复制问题和解决方案

View File

@@ -0,0 +1,6 @@
什么是可扩展性
读限制与写限制工作负载
功能拆分
使用读池扩展读
排队机制
使用分片扩展写

View File

@@ -0,0 +1,40 @@
## 什么限制了MySQL的性能
CPU 耗尽I/O 饱和,内存耗尽
## 如何为 MySQL 选择 CPU
- 低延迟(快速响应时间)
- 高吞吐量
平衡内存和磁盘资源
缓存、读取和写入
- 多次写操作,一次刷新
- I/O 合并
## 固态存储
## RAID 性能优化
在数据冗余,存储空间大小,缓存和速度方面提供一些帮助
- RAID 0
- RAID 1
- RAID 5
- RAID 6
- RAID 10
- RAID 50
## 网络配置
一个典型的应用程序会进行很多次小的网络传输,每次传输都会有轻微的延迟
## 选择文件系统
WIndowsNTFS
GUN/Linuxext4xfs

View File

@@ -0,0 +1,6 @@
为什么查询速度回慢
慢查询基础:优化数据访问
重构查询的方式
查询执行的基础
MySQL 查询优化器的局限性
优化特定类型的查询

View File

@@ -0,0 +1,26 @@
[[MySQL 架构]]
[[可靠性工程世界中的监控]]
[[Performance Scheme]]
[[操作系统和硬件优化]]
[[优化服务器设置]]
[[scheme设计与管理]]
[[创建高性能的索引]]
[[查询性能优化]]
[[复制]]
[[备份与恢复]]
[[扩展MySQL]]
[[云端的MySQL]]
[[MySQL的合规性]]