一名合格的后端开发，到底需要多了解mysql - 3&4&5

3 - 文件

mysql使用哪些文件

• 配置文件

  • 配置mysql启动时的各项参数

• 日志文件

  • 错误日志
  • 二进制日志
  • 慢日志
  • 查询日志
• pid文件
• unix domain socket文件
• 表结构文件
• 存储引擎管理的文件

二进制文件

事务提交时，在其实际提交前，mysql会将该事务写入binlog

主要使用场景：

• 数据恢复：备份+binlog恢复到某个时间点
• 主从复制：从节点实时消费binlog
• 监听数据库变更（审计，其他数据库同步等）

binlog和redolog的写入要求是原子的，否则当mysql宕机时，binlog中记录的事务实际没有提交，会默认被回滚，导致复制出现数据不一致。mysql借用分布式事务的二阶段提交来解决原子写入问题，在第七节进行详细分析。

binlog的格式：

• STATEMENT：记录逻辑sql语句，在RC隔离级别下可能会出现更新丢失
• ROW：记录行的变更情况

innodb存储引擎文件

• 表空间文件：存储一张表相关的所有数据

• redolog：mysql事务持久化的核心文件

  • 内容：每个被修改页的更改的物理情况
  • 时机：事务提交过程中，不断写入
  • 所有需要持久化的数据都受redolog保护，包括buffer pool或者说表空间内所有的数据

4 - 表

表中数据的组织形式

表空间首先根据数据的性质进行分段，分为以下几段：

• 聚集索引叶子节点段（即实际上的数据段）
• 聚集索引非叶子节点段（聚集索引b+树）
• 辅助索引段
• insert_buffer bitmap

还有一些数据只在共享表空间内存放：

• 回滚段
• insert_bufer
• 事务信息
• 二次写缓冲

每一段又被分为区（1MB），页（16kB）进行管理。

所有行数据是组织在聚集索引的b+树的叶子结点上进行存储。因此一张表只有一个聚集索引，其余索引都是辅助索引。
聚集索引按以下顺序挑选：主键 -> 第一个非空唯一索引 -> innodb为每行数据生成一个_rowid

每行数据的组织形式

• Compact:
  变长字段长度列表 - null标志位 - 记录头信息 - 列1数据 - 列2数据 - ......
• Redundant:
  字段长度偏移列表 - 记录头信息 - 列1数据 - 列2数据 - ......
• Dynamic:
  在Compact基础上，将BLOB信息完全存放在BLOB页中，不跟随行数据存放
• Compressed:
  在Dynamic基础上，行数据会以zlib算法进行压缩

每页数据的组织形式

• File Header：记录了页的偏移量，LSN，以及作为B+叶子结点的上下节点
• Page Headr：负责管理页内具体的数据
• Infimum, Supremum Records：记录页内所有数据的上界和下界
• User Records：行数据
• Free Spaces：空闲空间
• Page Directory：记录索引key和行的映射关系
• File Trailer：保证页的写入完整

5 - 索引和算法

innodb支持的索引

• B+树索引：数据页，索引页
• hash索引：自适应哈希
• 倒排索引：全文索引

B+树

B+树是为磁盘或其他直接存取辅助设备设计的一种平衡查找树。B+树分为叶子结点和非叶子结点，数据只存放在叶子节点上，非叶子节点只存放键值和指向子节点的指针。

为什么使用B+树不使用常见的二叉树？

B+树可以近似理解为一颗平衡多叉树，其复杂度和二叉树一样也是O(log n)。作为多叉树，每个节点拥有更多子节点，即便在千万数据量级下，也可以做到在个位数IO次数内，找到目标数据。

联合索引

通过多个字段确定顺序的索引，多个字段按优先级进行排序

覆盖索引

需要查询的数据可以直接从索引字段中得到，不用再访问聚集索引。
对于某些统计信息，比如count()也可能会通过辅助索引直接获取。

Multi Range Read

从辅助索引中读取聚集索引时，如果是批量获取数据，innodb会先在内存中对要查询的主键进行排序，再对排序后的主键进行访问。可以减少离散读的次数，降低总IO次数。

Index Condition Pushdown

Mysql 5.6 开始支持将where内能被索引覆盖的条件直接交给存储引擎判断。

哈希索引

innodb只在自适应哈希索引中使用了哈希索引。

倒排索引

innodb的全文索引使用倒排索引来实现。

关于B+树，哈希表和倒排索引的具体实现，可以参考其他资料。