Open
Description
MySQL技术内幕 InnoDB 存储引擎 第2版
第1章 MySQL 体系结构和存储引擎
1.1 定义数据和实例
数据库 database
物理操作系统文件或其他形式文件类型的集合。
在 MySQL 数据库中，数据库文件可以是 frm, MYD, MYI, idb 结尾的文件。
当使用 NDB 引擎时，数据库的文件可能不是操作系统上的文件，而是存放与内存之中
实例 instance
MySQL 数据库由后台线程以及一个共享内存区组成。数据库实例才是真正用于操作数据库文件的
MySQL 数据库实例在系统上的表示就是一个进程
1.2 MySQL 体系结构
图 1-1 MySQL 体系结构
MySQL 由以下几部分组成
1.连接池组建
2.管理服务和工具组建
3.SQL 接口组件
4.查询分析器组件
5.优化器组件
6.缓冲组件
7.插件式存储引擎
存储引擎是基于表的，而不是数据库
8.物理文件
1.3 MySQL 存储引擎
1.3.1 InnoDB 存储引擎
其设计目标主要面向在线事务处理（OLTP, Online Transction Processing）的应用
支持事务
行锁设计
支持外键
支持非锁定读
从5.5.8版本开始，InnoDB 存储引擎是默认存储引擎
idb 文件
1.3.2 MyISAM 存储引擎
面向OLAP （Online Analytical Processing） 数据库应用
不支持事务
表锁设计
支持全文索引
MYD 存放数据，MYI 存放索引
1.3.* XXXX 存储引擎
1.4 各存储引擎之间的比较
图 1-2 不同 MySQL 存储引擎相关特性比较
1.5 连接 MySQL
1.5.1 TCP/IP
1.5.2 命名管道和共享内存
1.5.3 UNIX 域套接字
1.6 小结
第2章 InnoDB 存储引擎
2.1 InnoDB 存储引擎概述
2.2 InnoDB 存储引擎的版本
2.3 InnoDB 体系架构
2.3.1 后台线程
InnoDB 存储引擎是多线程模型，后台线程有多个，负责处理不同任务
1.Master Thread
异步刷新缓存池中的数据到磁盘
2.IO Thread
InnoDB 存储引擎中大量使用了 AIO（Async IO）来处理写 IO 的请求，
这样可以极大提高数据库的性能。IO Thread 的主要工作是负责这些 IO 请求的回调
3.Purge Thread
事务被递交后，其所使用的 undolog 可能不再需要，
因此需要Purge Thread 来回收已经使用并分配的 undo 页
2.3.2 内存
1.缓冲池
缓冲池中缓存的数据页类型有
索引页
数据页
undo页
插入缓冲 insert buffer
自适应哈希索引 adaptive hash index
InnoDB 存储的锁信息
数据字典信息 data dictionary
2.LRU List，Free List 和 Flush List
缓冲池中页的默认大小是 16K
midpoint insertion strategy
新读取到的页不是放到 LRU 首部，而是放到 midpoint(5/8位置) 位置
midpoint 位置可由参数 innodb_old_blocks_pct 控制
midpoint 之前的列表称为 new 列表，之后为 old 列表
innodb_old_blocks_time 用于表示页读取到 midpoint 位置后多久才加入 midpoint 前
防止全表扫描对缓冲区造成污染
数据库启动时，LRU 列表是空的，页都存放在 Free 列表中，需要时从 Free 中取一个放到 LRU 中
LRU 列表的 old 部分加入 new 部分时，发生的操作称为 page made young，
若因为 innodb_old_blocks_time 而没有加入 new，称为 page not made young
通过 show engine innodb status 可以看到
Buffer pool size * 16K 是缓冲池的大小
Free buffers 表示 Free 列表页的数量
Database pages 表示 LRU 列表页中的数量
Buffer pool hit rate 缓冲池命中率，一般不应该小于95%
3.重做日志缓冲
redo log buffer, 重做日志缓冲区大小由 innodb_log_buffer_size 控制，默认为 8MB
下列三种情况会将重做日志缓冲区内容刷新到磁盘
1.Master Thread 每一秒将重做日志内容刷新到重做日志文件
2.每个事务递交时
3.当重做日志缓冲池剩余空间小于1/2时
4.额外的内存池
2.4 Checkpoint 技术
为了避免缓冲池中的页刷新到磁盘时发生宕机，事务数据库普遍采用 Write Ahead Log 策略，即当事务递交时，
先写重做日志，再修改页。
检查点技术（Checkpoint）技术的目的是解决以下几个问题：
1.缩短数据库的恢复时间
2.缓冲池不够用时，将脏页刷新到磁盘
3.重做日志不可用时，刷新脏页
两种 Checkpoint
1.Sharp Checkpoint
再数据库关闭时将所有的脏页都刷新回磁盘，默认方式，innodb_fast_shutdown=1
运行时使用，会降低可用性
2.Fuzzy Checkpoint
只刷新一部分脏页
Master Thread Checkpoint
FLUSH_LRU_LIST Checkpoint
Async/Sync Flush Checkpoint
Dirty Page too much Checkpoint
2.5 Master Thread 工作方式
2.5.1 InnoDB 1.0.x 版本之前的 Master Thread
Master Thread 具有最高的线程优先级别，其内部由多个循环组成
主循环 loop
后台循环 background loop
刷新循环 flush loop
暂停循环 suspend loop
Master Thread 每秒一次的操作包括
1.日志缓冲刷新到磁盘，即使这个事务还没有提交（总是）
大事务提交时间短的原因
2.合并插入缓冲（可能）
3.至多刷新100个 InnoDB 的缓冲池中的脏页到磁盘（可能）
4.如果当前没有用户活动，则切换到 background loop （可能）
Master Thread 每10秒的操作，包括如下内容
1.刷新100个脏页到磁盘（可能的情况下）
2.合并至多5个插入缓冲（总是）
3.将日志缓冲刷新到磁盘（总是）
4.删除无用的 Undo 页（总是）
5.刷新100个或者10个脏页到磁盘（总是）
background loop
没有用户活动，或者数据库关闭时，会切换到这个循环
1.删除无用的 Undo 页（总是）
2.合并20个插入缓冲（总是）
3.跳回到主循环（总是）
4.不断刷新100个页直到符合条件（可能，跳转到 flush loop 中完成）
2.5.2 InnoDB 1.2.x 版本之前的 Master Thread
基于 SSD 硬盘的的优化
innodb_io_capacity
2.5.3 InnoDB 1.2.x 版本的 Master Thread
2.6 InnoDB 关键特性
1.插入缓冲 Insert Buffer
2.两次写 Double Write
3.自适应哈希索引 Adaptive Hash index
4.异步IO Async IO
5.刷新领接页 Flush Neibhor Page
2.6.1 插入缓冲
1.Insert Buffer
对于非聚集索引（相对与自增主键而言）的插入或者更新操作，不是每一次直接插入索引页中，
而是先判断插入的非聚集索引页是否在缓冲池中，若在则直接插入；若不在，则先放到 Insert Buffer 对象中，
好似欺骗数据库这个非聚集索引已经插入到叶子节点，而实际并没有。
然后再以一定的频率和情况进行 Insert Buffer 的辅助索引子页面的 merge 操作，这时通常能将多个插入合并到一个操作中，
因为在一个索引中，这就大大提高了对于非聚集索引插入的性能
Insert Buffer 的使用需要同时满足以下两个条件
1.索引是辅助索引 secondary index
2.索引不是唯一 unique 的
使用 show engine innodb status 可以查看相关信息，其中的
inserts 代表插入的记录数
merged recs 代表合并的插入记录数量
merges 代表合并的次数
merged recs : merges 代表提升的插入效率
Insert Buffer 有一个问题，在写密集的情况下，插入缓冲会占用过多缓冲池内存，默认可占到 1/2
2.Change Buffer
3.Insert Buffer 的内部实现
B+ 树
非叶节点
space | marker | offset
表空间id | 兼容 | 偏移量
叶节点
space | marker | offset | metadata | (secondary index record)
表空间id | 兼容 | 偏移量 |
4.Merge Insert Buffer
发生情况
1.辅助索引页被读取到缓冲池时
2.Insert Buffer Bitmap 页追踪到该辅助索引页已无空间可用时
3.Master Thread
2.6.2 两次写
doublewrite 带给 InnoDB 的是数据页的可靠性
2.6.3 自适应哈希索引 Adaptive Hash Index
2.6.4 异步IO （AIO）
异步 IO 的一个好处可以进行 IO Merge
2.6.5 刷新邻接页
2.7 启动、关闭与恢复
innodb_fast_shutdown
0 数据库关闭时，InnoDB 需要完成 full purge 和 merge insert buffer，
脏页刷新回磁盘
1 默认值，缓冲池中的一些数据脏页刷新回磁盘
2 只写日志
innodb_force_recovery
0 默认值，表示需要恢复时，进行所有恢复
1 忽略检查到的 corrupt 页
2 阻止 Master Thread 线程的运行
3 不进行事务的回滚操作
4 不进行插入缓冲的合并操作
5 不查看撤销日志
6 不进行前滚操作
第3章 文件
3.1 参数文件
3.1.1 什么是参数
3.1.2 参数类型
动态参数
运行时可以更改
静态参数
生命周期内不可更改
3.2 日志文件
3.2.1 错误日志
mysql> show variables like 'log_error';
3.2.2 慢查询日志
mysql> show variables like 'long_query_time';
mysql> show variables like 'log_slow_queries';
mysql> show variables like 'log_queries_not_using_indexes';
mysqldumpslow
logical reads --- physical reads
3.2.3 查询日志
3.2.4 二进制日志
不记录 select 和 show
开启后性能下降 1%
作用
恢复
复制
审计
mysql> show variables like 'binlog_cache_size';
mysql> show global status like 'binlog_cache%';
binlog_format
STATEMENT
ROW
MIXED
3.3 套接字文件
mysql> show variables like 'socket';
3.4 pid 文件
mysql> show variables like 'pid_file';
3.5 表结构定义文件
*.frm
3.6 InnoDB 存储引擎文件
3.6.1 表空间文件
innodb_data_file_path
*.ibd
3.6.2 重做日志文件
ib_logfile0
ib_logfile1
mysql> show variables like 'innodb%log%';
与二进制日志的差别
二进制记录所有相关日志，重做日志只记录该存储引擎本身的事务日志
记录内容不同，重做日志记录的是关于每个页 Page 的更改的物理情况
写入时间也不一样
重做日志条目结构
redo_log_type | space | page_no | redo_log_body
第4章 表
4.1 索引组织表
在 innodb 存储引擎中，表都是根据主键顺序组织存放的，这种存储方式的表称为索引组织表 （index orgenized table）
每个表都要有主键，若没有显示指定，则按照下列规则自动创建
1.判断表中是否有非空的唯一索引，有即为主键
2.在1没有的情况下，自动创建一个6字节大小的指针
4.2 Innodb 逻辑存储结构
表空间（tablespace） --> 段（segment） --> 区（extent） --> 页（page/block） --> 行（row）
4.2.1 表空间
Innodb 逻辑结构的最高层，所有数据在其中，包括
回滚信息
插入缓冲索引页索引
系统事务信息
二次写缓冲
当用户设置 innodb_file_per_table 之后，以下信息就存放在了单独的一个表空间内
数据
索引
插入缓冲 Bitmap 页
4.2.2 段
数据段
索引段
回滚段
4.2.3 区
4.2.4 页
数据页 B-tree Node
undo页 undo Log Page
系统页 System Page
事务数据页 Transction system Page
插入缓冲位图页 Insert Buffer Bitmap
插入缓冲空闲列表页 Insert Buffer Free List
未压缩的二进制大对象页 Uncompressed BLOB Page
压缩的二进制大对象页 compressed BLOB Page
4.2.5 行
4.3 InnoDB 行记录格式
mysql> show table status like 'my_table_name';
4.3.1 Compact 行记录格式
变长字段长度列表 | null 标识位 | 记录头信息 | 列1数据 | 列2数据 ...
4.3.2 Redundant 行记录格式
字段长度偏移列表 | 记录头信息 | 列1数据 | 列2数据 ...
4.3.3 行溢出数据
4.3.4 compressed 和 Dynamic 行记录格式
4.3.5 Char 的行存储结构
4.4 InnoDB 数据页结构
4.4.1 File Header
4.4.2 Page Header
4.4.3 Infimum 和 Supremum record
4.4.4 User Record 和 Free space
4.4.5 Page Directory
4.4.6 File Trailer
4.5 Named File Formats 机制
4.6 约束
4.6.1 数据完整性
Primary Key
Unique Key
Foreign Key
Default
NOT NULL
4.6.2 约束的创建和查找
表建立时进行约束定义
利用 alter table 命令创建约束
4.6.3 约束和索引的区别
4.6.4 对错误数据的约束
4.6.5 ENUM 和 SET 约束
4.6.6 触发器与约束
4.6.7 外键约束
4.7 视图
4.7.1 视图的作用
4.7.2 物化视图
4.8 分区表
4.8.1 分区概述
4.8.2 分区类型
1.range 分区
2.list 分区
3.hash 分区
4.key 分区
4.8.3 子分区
4.8.4 分区中的 null 值
4.8.5 分区和性能
4.8.6 在表和分区间交换数据
第5章 索引与算法
5.1 InnoDB 存储引擎索引概述
常见的索引
B 树索引
全文索引
哈希索引
自适应的
5.2 数据结构与算法
5.2.1 二分查找
5.2.2 二叉查找树和平衡二叉树
5.3 B+ 树
高度、每页存放记录数、扇出
B+ 树的非叶子节点不保存数据，只保存索引；B 树
B+ 树的叶子节点是彼此连接的，B 树没有
B+ 树的叶子节点包含了所有数据，B 树只包含了部分，另一部分在非叶子结点
https://github.com/Shellbye/Shellbye.github.io/issues/55
5.3.1 B+ 树的插入操作
Leaf Page 满 | Index Page 满 | 操作
No No 直接将记录插入到叶子节点
1.拆分 Leaf Page
Yes No 2.将中间的节点放入到 Index Page 中
3.小于中间节点的记录放左边
4.大于或等于的放右边
--------------------------------------------------------------------
1.拆分 Leaf Page
2.小于中间节点的记录放左边
3.大于或等于的放右边
Yes Yes 4.拆分 Index Page
5.小于中间节点的记录放左边
6.大于中间节点的记录放右边
7.中间节点放入上一层 Index Page
5.3.2 B+ 树的删除操作
叶子结点小于填充因子 | 中间结点小于填充因子 | 操作
No No 直接将记录从叶子结点删除，
如果该结点还是 Index Page 的结点，
用该结点的右结点替代
--------------------------------------------------------------------
Yes No 合并叶子结点和它的兄弟结点，更新 Index Page
--------------------------------------------------------------------
1.合并叶子结点和它的兄弟结点
Yes Yes 2.更新 Index Page
3.合并 Index Page 和它的兄弟结点
5.4 B+ 树索引
聚集索引与辅助索引不同的是，叶子结点存放的是否是一整行的信息
5.4.1 聚集索引
叶子结点存放的就是一整行的信息
5.4.2 辅助索引
叶子结点存放的不是一整行信息，而是指向聚集索引位置的指针
5.4.3 B+树索引的分裂
5.4.4 B+树索引的管理
1.索引管理
mysql> show index from table_name;
Table
Non_unique
Key_name
Seq_in_index 联合索引中区分列
Column_name 索引列的名称
Collation 存放方式，B+树索引总是 A，如果使用了 Heap 存储引擎并建立了 Hash 索引，这里就显示 NULL
Cardinality 表示索引中唯一值的数据的估计值。唯一性，越大越唯一
Sub_part 是否是列的部分被索引
Packed 如何压缩关键字
Null 索引的列是否含有 NULL 值
Index_type 索引的类型，BTREE
Comment 注释
mysql> analyze table table_name;
2.Fast Index Creation
3.Online Scheme Change
源自 facebook 的 PHP 脚本
4.Online DDL
5.5 Cardinality 值
5.5.1 什么是 Cardinality
5.5.2 InnoDB 存储引擎的 Cardinality 统计
5.6 B+树索引的使用
5.6.1 不同应用中 B+ 树索引的使用
5.6.2 联合索引
设计的比较好的时候，可以避免一次多余的排序
5.6.3 覆盖索引
辅助索引直接查到记录，不需要走聚合索引，减少 IO 操作
5.6.4 优化器选择不使用索引的情况
5.6.5 索引提示
5.6.6 Multi-Range Read 优化
好处
MRR 使数据访问变得较为顺序
减少缓冲池中页被替换的次数
批量处理对键值的查询操作
工作方式
1.将查询得到的辅助索引键值存放于一个缓存中，此时是按照辅助索引键值排序的
2.将缓存中的键值根据 RowID 进行排序
3.根据 RowID 的排序顺序来访问实际的数据文件
5.6.7 Index Condition Pushdown 优化
将 where 条件的过滤放在了存储引擎层
5.7 哈希算法
5.7.1 哈希表
h(k) = k mod m
5.7.2 InnoDB 存储引擎中的哈希算法
5.7.3 自适应哈希索引
5.8 全文索引
5.8.1 概述
5.8.2 倒排索引
5.8.3 InnoDB 全文索引
full inverted index
文档，位置
word 存放在 Auxiliary Table 中
FTS Index Cache 全文检索索引缓存
红黑树
关闭时会同步到 Auxiliary Table 中
FTS Document ID
与 word 对应的列
stopword
5.8.4 全文检索
1.Natural Language
2.Boolean
3.Query Expansion
第6章 锁
6.1 什么是锁
锁机制用于管理对公共资源的并发访问
InnoDB内部不光对表数据上锁，还会对内部的其他资源进行加锁，比如LRU列表
6.2 lock 和 latch
latch 一般称谓闩锁（轻量级的锁），因为其要求的锁定时间必须非常短
mutex
rwlock
lock 的对象是事务
------------------------------------------------------------------------
|lock | latch
------------------------------------------------------------------------
对象 | 事务 | 线程
------------------------------------------------------------------------
保护 | 数据库内容 | 内存数据结构
------------------------------------------------------------------------
持续 | 整个事务过程 | 临界资源
------------------------------------------------------------------------
模式 | 行锁,表锁,意向锁 | 读写锁，互斥量
------------------------------------------------------------------------
死锁 | 通过 waits-for gragh | 无死锁监测与处理机制。
| time out 等机制进行死锁监测 | 仅通过应用程序加锁的顺序（lock leveling）保证无死锁的情况发生
| 与处理
------------------------------------------------------------------------
存在于 | Lock Manager 的哈希表中 | 每个数据结构的对象中
------------------------------------------------------------------------
6.3 InnoDB 存储引擎中的锁
6.3.1 锁的类型
共享锁 （S Lock）
允许事务读一行数据
排他锁 （X Lock）
允许事务删除或更新一行数据
意向锁 （Intension Lock）
意向共享锁（IS Lock）
事务想要获得某几行的共享锁
意向排他锁（IX Lock）
事务想要获得某几行的排他锁
INNODB_TRX
INNODB_LOCK
INNODB_LOCK_WAITS
6.3.2 一致性非锁定读
不需要等待 X 锁的释放，直接读取其他快照
一行记录可能有不止一个快照数据，一般称为行多版本技术；
由此带来的并发技术，称为多版本并发控制（Multi Version Concurrent Control，MVCC）
事务的隔离级别
REPEATABLE READ
读取事务开始时的版本
READ COMMITED
读取最新版本
6.3.3 一致性锁定读
1.select ... for update
加 X 锁
2.select ... lock in share mode
加 S 锁
6.3.4 自增长与锁
6.3.5 外键和锁
6.4 锁的算法
6.4.1 行锁的三种算法
1.Record Lock
单个行记录上的锁
2.Gap Lock
间隙锁，锁定范围，但不包含记录本身
3.Next-key Lock
Gap Lock + Record Lock ，锁定一个范围和记录本身
6.4.2 解决 Phantom Problem （幻象问题）
Phantom Problem 指在同一个事务中，同一个 SQL 返回了不同的结果
InnoDB 通过使用 Next-key Lock 来解决 Phantom Problem，即锁住未来几行
6.5 锁问题
6.5.1 读脏
6.5.2 不可重复读
6.5.3 丢失更新
6.6 阻塞
非死锁的资源等待
innodb_lock_wait_timeout
控制等待时间，默认50s
innodb_rollback_on_timeout
是否在等待超时之后对进行中的事务进行回滚，默认 off ，表示不回滚
6.7 死锁
6.7.1 死锁的概念
死锁是指两个或以上的事务在执行过程中，因争夺资源而造成的一种互相等待的现象。
wait-for graph (等待图)
锁的信息链表
事务等待链表
6.7.2 死锁概率
6.7.3 死锁的示例
6.8 锁升级
行锁-->页锁-->表锁
锁升级会带来效率提升，但是会导致并发下降
第7章 事务
事物（Transaction）是数据库区别于文件系统的重要特性之一
ACID
原子性 Atomicity
一致性 Consistency
隔离性 Isolation
持久性 Durability
7.1 认识事务
7.1.1 概述
7.1.2 分类
扁平事务
带有保存点的扁平事务
链事务
嵌套事务
分布式事务
7.2 事务的实现
隔离性由锁来实现，原子性、持久性通过数据库的 redo log， 一致性通过 undo log 来完成
7.2.1 redo
1.基本概念
重做日志缓冲 redo log buffer
重做日志文件 redo log file
innodb_flush_log_at_trx_commit
用来控制重做日志刷新到磁盘的策略，默认为1，表示每次提交事务刷新
非1会提高一定的性能
2.log block
每块 512 字节
3.log group
4.重做日志格式
5.LSN Log Sequence Number
6.恢复
物理日志，恢复速度快，且幂等（可重做）
7.2.2 undo
1.基本概念
用于回滚，逻辑修改
2.undo 存储管理
3.undo log 格式
4.查看 undo 信息
7.2.3 purge
purge 用于最终完成 delete 和 update 操作
7.2.4 group commit
为了提高磁盘 fsync 的效率，一次 fsync 可以刷新确保多个事务日志被写入文件
事务递交时会进行两个阶段的操作
1.修改内存中事务对应的信息，并且将日志写入重做日志缓冲
2.调用 fsync 将确保日志都从重做日志缓冲写入磁盘
Binary Log Group Commit (BLGC)
MySQL 数据库上层进行递交时，首先按顺序将其放入一个队列中，队列中的第一个事务称为 leader，
其他事务称为 follower ， leader 控制这 follower 的行为
1.Flush 阶段，将每个事务的二进制日志写入内存中
2.Sync 阶段，将内存中的二进制日志刷新到磁盘，若队列中有多个事务，
那么仅一次 fsync 操作就完成了二进制日志的写入，这就是 BLGC
3.Commit 阶段，leader 根据顺序调用存储引擎层事务的递交
7.3 事务控制语句
START TRANSCTION | BEGIN
COMMIT
ROLLBACK
SAVEPOINT identifier
RELEASE SAVEPOINT identifier
ROLLBACK TO [SAVEPOINT] identifier
SET TRANSCTION
7.4 隐式递交的 SQL 语句
DDL 语句等
7.5 对于事务操作的统计
每秒事务处理能力 Transction per second TPS
7.6 事务的隔离级别
READ UNCOMMITTED
READ COMMITED
REPEATABLE READ
SERIALIZABLE
7.7 分布式事务
7.7.1 MySQL 数据库分布式事务
7.7.2 内部 XA 事务
7.8 不好的事务习惯
7.8.1 在循环中提交
7.8.2 使用自动递交
7.8.3 使用自动回滚
7.9 长事务
第8章 备份与恢复
8.1 备份与恢复概述
Hot backup (Online backup)
Cold backup (Offline backup)
Warm backup
mysqldump --single-transction
8.2 冷备
直接操作存储文件
8.3 逻辑备份
8.3.1 mysqldump
8.3.2 select ... into outfile
8.3.3 逻辑备份的恢复
# mysql -uroot -p < backup.sql
mysql> source /path/to/backup.sql
8.3.4 load data infile
8.3.5 mysqlimport
8.4 二进制日志备份与恢复
开启
[mysqld]
log-bin = mysql-bin
sync_binlog = 1
innodb_support_xa = 1
还原
# mysqlbinlog [options] log_file...
# mysqlbinlog binlog.000001 > /tmp.sql
# mysql -u root -p -e "source /tmp.sql"
8.5 热备
8.5.1 ibbackup (收费软件, 免费版本 Percona 开发的 XtraBackup )
工作原理
1.记录备份开始时， InnoDB 存储引擎重做日志文件检查点的 LSN
2.复制共享表空间文件以及独立表空间文件
3.记录复制完表空间文件后， InnoDB 存储引擎重做日志文件检查点的 LSN
4.复制在备份时产生的重做日志
ibbackup 优点
1.在线备份，不阻塞任何的 SQL 语句
2.备份性能好，备份的实质是复制数据库文件和重做日志文件
3.支持压缩备份，通过选项可以支持不同级别的压缩
4.跨平台支持
恢复步骤
1.恢复表空间文件
2.应用重做日志文件
8.5.2 XtraBackup
8.5.3 XtraBackup 实现增量备份
8.6 快照备份
MySQL 本身不支持，依赖文件系统
8.7 复制
8.7.1 复制的工作原理
复制 replication 是 MySQL 数据库提供的一种高可用高性能的解决方案
工作原理分为以下三个步骤
1.主服务器把数据更改记录到二进制日志中
2.从服务器把主服务器的二进制日志复制到自己的中继日志中
3.从服务器重做中继日志中的日志，把更改应用到自己的数据库上
8.7.2 快照 + 复制的备份架构
第9章 性能调优