第一章-MySQL架构与历史

——「高性能MYSQL」读书笔记（第一章）

《高性能****MYSQL》

MYSQL经典书籍，常读常新。

本章概要地描述了 MySQL 的服务器架构、各种存储引擎之间的主要区别，以及这些区别的重要性。通过简化细节和演示案例来讨论 MySQL 的原理和基础知识。

• 第一层 -连接层： 用于连接、线程处理，处理连接、授权认证、安全等。

• 第二层 -服务层：这一层包含MySQL大多数的核心服务：比如查询的解析、分析、优化、缓存和所有的内置函数，跨存储引擎功能都在这一层：存储过程、触发器、试图等。本书后续内容中。这部分也是重点。

• 第三层 -引擎层：MySQL 中真正负责数据的存储和提取的存储引擎（InnoDB、MyISAM等）。服务器通过API与存储引擎进行通信，这一层接口对服务层隔离了不同存储引擎的差异。各个存储引擎之间是相互独立的。存储引擎提供一些底层函数，而我们对数据库的大多操作都会最后分解成这些函数调用，比如：开始一个事务 或者 根据主键提取一行数据。

查询语句的执行流程

• 查询缓存（命中）->权限校验

• 查询缓存（未命中）->分析器->优化器->权限校验->执行器->引擎

• 读锁（共享锁）

• 写锁（排他锁）

• 全局锁：对整个数据库实例加锁，加锁后整个实例就处于只读的状态，多用于数据库备份。

• **表锁：**MySQL中最基本的锁策略，也是开销最小的策略。

• **行锁：**只在存储引擎中实现，MySQL服务器层完全不了解存储引擎中的锁实现

• 页级锁：粒度介于行级锁和表级锁中间的一种锁，一次锁定相邻的一组记录。

• **READ UNCOMMITTED（读未提交）：**事务中的修改，即使没有提交，其他事务也能够读到。

• **READ COMMITTED（读已提交）：**事务只能看见已经提交的的事务所做的修改。

• **REPEATABLE READ（可重复读）：**该级别保证同一个事务中多次读取同样的记录的结果是一致的。并且InnoDB通过MVCC解决了幻读的问题。

• **SERIALIZABLE（可串行化）：**强制事务串行执行，SERIALIZABLE会在读取的每一行数据上都加锁。

• 脏读：读取未提交数据

• 不可重复读：前后多次读取，数据内容不一致

• 幻读：前后多次读取，数据总量不一致

• 指两个或多个事务在统一资源上相互占用，并请求锁定对方占用的资源，从而导致的恶性循环的现象。

• InnoDB目前处理死锁方式为，将持有最少行级排他锁的事务进行回滚。

事务日志可以帮助提髙事务的效率。

存储引擎在修改表的数据时只需要修改其内存拷贝，再把该修改行为记录到持久在硬盘上的事务日志中（顺序****IO），而不用每次都将修改的数据本身持久到磁盘。事务日志持久以后，内存中被修改的数据在后台可以慢慢地刷回到磁盘（随机IO）。

如果数据的修改已经记录到事务日志并持久化，但数据本身还没有写回磁盘，此时系统崩溃，存储引擎（innoDB）在重启时能够自动恢复这部分修改的数据。

在事务中混合使用存储引擎

• MySQL服务器层不管理事务，事务是由下层的存储引擎实现的。所以在同一个事务中，使用多种存储引擎是不可靠的

• 如果混合使用了事务型和非事务型的表（InnoDB和MyISAM）当事务需要回滚时，非事务型表才会发出一个警告，大多数情况下，对非事务型表的操作都不会有提示。

• 书中建议，除了事务中禁用了AUTOCOMMIT，可以使用LOCK TABLES之外，其他任何时候都不要显式地执行LOCK TABLES。（）

MVCC是通过保存数据在某个时间点的快照来实现的，不同版本的MVCC的实现不同，这里主要介绍了InnoDB的简化版本来说明MVCC

InnoDB的MVCC通过每行记录后的两个隐藏列来实现的：「行的创建时间」、「行的过期时间」。这两列存储的是系统版本号，每开始一个新的事务，系统版本号都会自动递增。 下面是在REPEATABLE READ隔离级别下，MVCC的操作

• SELECT

• INSERT

• DELETE

• UPDATE（插入b删除a）

当前MySQL默认的存储引擎。支持事务，行级锁，自动崩溃恢复的特性。InnoDB表是基于聚簇索引简历的，所以表也就是主索引本身。

5.1及之前版本的默认存储引擎。之前全文索引、压缩、空间函数（GIS）等。但是不支持事务和行级锁。也不支持崩溃后安全恢复。对于只读数据或表比较小、可以忍受修复操作，可以使用MyISAM。

数据文件和索引文件，.MYD和.MYI。

还有更多存储引擎就不一一记录了。对于存储引擎的选择，可以简单归纳为一句话：除非需要用到某些InnoDB不具备的特性，并且没有其他办法可以替代，否则都应该优先选择InnoDB引擎

MySQL常用存储引擎对比

选择合适的存储引擎，需要考虑的因素

1. 事务

   应用需要事务，InnoDB是目前最稳定并且经过验证的选择，如果不需要，MyISAM是日志型应用的选择。

2. 备份

   如果需要在线热备，那么应该考虑 InnoDB。如果可以定期关闭服务器进行冷备，那么备份这个因素可以忽略掉。

3. 崩溃恢复

   MyISAM崩溃后损坏概率比InnoDB高，且恢复也慢。

   特别是数据量比较大的应用场景，数据库崩溃后，是否能快速恢复是一个非常重要的因素。

   一般来讲，如果应用场景特别复杂，以至于搞不清楚需求，无法确定应该使用哪种存储引擎，那么就使用 InnoDB 吧，这是比较安全的选择。

4. 特有的特性

目前，很多公司都会在MySQL基础上自研数据库，像字节的新服务包很多使用的都是字节跳动自研的ByteNDB（ByteDance NewSQL Database），他100%兼容MySQL，使用者可以像使用MySQL一样使用ByteNDB。所以也参考了一些资料了解ByteNDB与MySQL对比做的优化。

ByteNDB是一个分布式数据库，由3个子系统构成：

• DB Engine：无状态的数据库实例，负责处理事务；目前分为Read-Write节点和Read-Only节点；同机房共享一份数据，备库靠回放redo log同步数据，跨机房的从库通过binlog逻辑复制。

• LogStore：分布式redo log存储系统，负责数据库事务日志的持久化存储

• PageStore：分布式数据库存储系统，负责数据库表数据的持久化存储

	ByteNDB	MySQL
部署形态	一主多备/多主	单机/一主多从
成本	计算存储分离，独立扩缩计算/存储，成本较低	计算存储耦合，无法独立扩缩，成本较高
灵活性	计算进程无状态，主备间无直接网络交互，不依赖本地存储	存储依赖local disk，主从之间需要网络交互，需要处理网络异常
可用性	可用性高，存储层多副本可跨机房部署	主从同步模式，跨机房要在pro和性能之间取舍
性能	高并发场景下，集群吞吐大	主从同步和从机消费影响性能