MySQL海量数据存储与优化（上）

MySQL 起源和分支

MySQL 是最流行的关系型数据库软件之一，由于其体积小、速度快、开源免费、简单易用、维护成本

低等，在集群架构中易于扩展、高可用，因此深受开发者和企业的欢迎。

Oracle 和 MySQL 是世界市场占比最高的两种数据库。

IOE ： IBM 的服务器， Oracle 数据库， EMC 存储设备。都是有钱的公司产品采购，例如银行、电信、石

油、证券等大企业。

Oracle ：垄断，有钱的大企业采用，互联网企业之外使用第一。

MySQL ：互联网高速发展，互联网企业使用第一。 MySQL 发展历程如下：

MySQL 主流分支如下图所示 MySQL 从最初的 1.0 、 3.1 到后来的 8.0 ，发生了各种各样的变化。被 Oracle 收购后， MySQL 的版本演化

出了多个分支，除了需要付费的 MySQL 企业版本，还有很多 MySQL 社区版本。还有一条分支非常流行

的开源分支版本叫 Percona Server ，它是 MySQL 的技术支持公司 Percona 推出的，也是在实际工作中经

常碰到的。 Percona Server 在 MySQL 官方版本的基础上做了一些补丁和优化，同时推出了一些工具。另

外一个非常不错的版本叫 MariaDB ，它是 MySQL 的公司被 Oracle 收购后， MySQL 的创始人 Monty 先

生，按原来的思路重新写的一套新数据库，同时也把 InnoDB 引擎作为主要存储引擎，也算 MySQL 的

分支。

第 4 节 MySQL 应用架构演变

本节主要介绍网站在不同的并发访问量级和数据量级下， MySQL 应用架构的演变过程。

用户请求 -- 》 应用层 -- 》服务层 -- 》存储层

架构 V1.0 - 单机单库

一个简单的小型网站或者应用背后的架构可以非常简单 , 数据存储只需要一个 MySQL Instance 就能

满足数据读取和写入需求（这里忽略掉了数据备份的实例），处于这个的阶段系统，一般会把所有

的信息存到一个 MySQL Instance 里面。

V1.0 瓶颈

数据量太大，超出一台服务器承受

读写操作量太大，超出一台服务器承受

一台服务器挂了，应用也会挂掉（可用性差）

架构 V2.0 - 主从架构 V2.0 架构主要解决架构 V1.0 下的高可用和读扩展问题，通过给 Instance 挂载从库解决读取的压力，

主库宕机也可以通过主从切换保障高可用。在 MySQL 的场景下就是通过主从结构（双主结构也属

于特殊的主从），主库抗写压力，通过从库来分担读压力，对于写少读多的应用， V2.0 主从架构

完全能够胜任。

V2.0 瓶颈

数据量太大，超出一台服务器承受

写操作太大，超出一台 M 服务器承受

架构 V3.0 - 分库分表

对于 V1.0 和 V2.0 遇到写入瓶颈和存储瓶颈时，可以通过水平拆分来解决，水平拆分和垂直拆分有

较大区别，垂直拆分拆完的结果，每一个实例都是拥有全部数据的，而水平拆分之后，任何实例都

只有全量的 1/n 的数据。以下图所示，将 Userinfo 拆分为 3 个 Sharding ，每个 Sharding 持有总量的

1/3 数据， 3 个 Sharding 数据的总和等于一份完整数据

数据如何路由成为一个关键问题， 一般可以采用范围拆分， List 拆分、 Hash 拆分等。

如何保持数据的一致性也是个难题。

架构 V4.0 - 云数据库 云数据库（云计算）现在是各大 IT 公司内部作为节约成本的一个突破口，对于数据存储的 MySQL

来说，如何让其成为一个 saas （ Software as a Service ）是关键点。 MySQL 作为一个 saas 服务，

服务提供商负责解决可配置性，可扩展性，多用户存储结构设计等这些疑难问题。

第一部分 MySQL 架构原理

第 1 节 MySQL 体系架构

MySQL Server 架构自顶向下大致可以分网络连接层、服务层、存储引擎层和系统文件层。

一、网络连接层

客户端连接器（ Client Connectors ）：提供与 MySQL 服务器建立的支持。目前几乎支持所有主流

的服务端编程技术，例如常见的 Java 、 C 、 Python 、 .NET 等，它们通过各自 API 技术与 MySQL 建立 连接。

二、服务层（ MySQL Server ）

服务层是 MySQL Server 的核心，主要包含系统管理和控制工具、连接池、 SQL 接口、解析器、查询优

化器和缓存六个部分。

连接池（ Connection Pool ） ：负责存储和管理客户端与数据库的连接，一个线程负责管理一个

连接。

系统管理和控制工具（ Management Services & Utilities ） ：例如备份恢复、安全管理、集群

管理等

SQL 接口（ SQL Interface ） ：用于接受客户端发送的各种 SQL 命令，并且返回用户需要查询的结

果。比如 DML 、 DDL 、存储过程、视图、触发器等。

解析器（ Parser ） ：负责将请求的 SQL 解析生成一个 " 解析树 " 。然后根据一些 MySQL 规则进一步

检查解析树是否合法。

查询优化器（ Optimizer ） ：当 “ 解析树 ” 通过解析器语法检查后，将交由优化器将其转化成执行计

划，然后与存储引擎交互。

select uid,name from user where gender=1;

选取 -- 》投影 -- 》联接 策略

1 ） select 先根据 where 语句进行选取，并不是查询出全部数据再过滤

2 ） select 查询根据 uid 和 name 进行属性投影，并不是取出所有字段

3 ）将前面选取和投影联接起来最终生成查询结果

缓存（ Cache&Buffffer ） ： 缓存机制是由一系列小缓存组成的。比如表缓存，记录缓存，权限缓

存，引擎缓存等。如果查询缓存有命中的查询结果，查询语句就可以直接去查询缓存中取数据。

三、存储引擎层（ Pluggable Storage Engines ）

存储引擎负责 MySQL 中数据的存储与提取，与底层系统文件进行交互。 MySQL 存储引擎是插件式的，

服务器中的查询执行引擎通过接口与存储引擎进行通信，接口屏蔽了不同存储引擎之间的差异 。现在有

很多种存储引擎，各有各的特点，最常见的是 MyISAM 和 InnoDB 。

四、系统文件层（ File System ）

该层负责将数据库的数据和日志存储在文件系统之上，并完成与存储引擎的交互，是文件的物理存储

层。主要包含日志文件，数据文件，配置文件， pid 文件， socket 文件等。

日志文件

错误日志（ Error log ）

默认开启， show variables like '%log_error%'

通用查询日志（ General query log ）

记录一般查询语句， show variables like '%general%';

二进制日志（ binary log ）

记录了对 MySQL 数据库执行的更改操作，并且记录了语句的发生时间、执行时长；但是它不

记录 select 、 show 等不修改数据库的 SQL 。主要用于数据库恢复和主从复制。

show variables like '%log_bin%'; // 是否开启

show variables like '%binlog%'; // 参数查看

show binary logs;// 查看日志文件

慢查询日志（ Slow query log ） 记录所有执行时间超时的查询 SQL ，默认是 10 秒。

show variables like '%slow_query%'; // 是否开启

show variables like '%long_query_time%'; // 时长

配置文件

用于存放 MySQL 所有的配置信息文件，比如 my.cnf 、 my.ini 等。

数据文件

db.opt 文件：记录这个库的默认使用的字符集和校验规则。

frm 文件：存储与表相关的元数据（ meta ）信息，包括表结构的定义信息等，每一张表都会

有一个 frm 文件。

MYD 文件： MyISAM 存储引擎专用，存放 MyISAM 表的数据（ data) ，每一张表都会有一个

.MYD 文件。

MYI 文件： MyISAM 存储引擎专用，存放 MyISAM 表的索引相关信息，每一张 MyISAM 表对

应一个 .MYI 文件。

ibd 文件和 IBDATA 文件：存放 InnoDB 的数据文件（包括索引）。 InnoDB 存储引擎有两种

表空间方式：独享表空间和共享表空间。独享表空间使用 .ibd 文件来存放数据，且每一张

InnoDB 表对应一个 .ibd 文件。共享表空间使用 .ibdata 文件，所有表共同使用一个（或多

个，自行配置） .ibdata 文件。

ibdata1 文件：系统表空间数据文件，存储表元数据、 Undo 日志等 。

ib_logfifile0 、 ib_logfifile1 文件： Redo log 日志文件。

pid 文件

pid 文件是 mysqld 应用程序在 Unix/Linux 环境下的一个进程文件，和许多其他 Unix/Linux 服务

端程序一样，它存放着自己的进程 id 。

socket 文件

socket 文件也是在 Unix/Linux 环境下才有的，用户在 Unix/Linux 环境下客户端连接可以不通过

TCP/IP 网络而直接使用 Unix Socket 来连接 MySQL 。

第 2 节 MySQL 运行机制 ①建立连接（ Connectors&Connection Pool ），通过客户端 / 服务器通信协议与 MySQL 建立连

接。 MySQL 客户端与服务端的通信方式是 “ 半双工 ” 。对于每一个 MySQL 的连接，时刻都有一个

线程状态来标识这个连接正在做什么。

通讯机制：

全双工：能同时发送和接收数据，例如平时打电话。

半双工：指的某一时刻，要么发送数据，要么接收数据，不能同时。例如早期对讲机

单工：只能发送数据或只能接收数据。例如单行道

线程状态：

show processlist; // 查看用户正在运行的线程信息， root 用户能查看所有线程，其他用户只能看自

己的

id ：线程 ID ，可以使用 kill xx ；

user ：启动这个线程的用户

Host ：发送请求的客户端的 IP 和端口号

db ：当前命令在哪个库执行

Command ：该线程正在执行的操作命令

Create DB ：正在创建库操作

Drop DB ：正在删除库操作

Execute ：正在执行一个 PreparedStatement

Close Stmt ：正在关闭一个 PreparedStatement

Query ：正在执行一个语句

Sleep ：正在等待客户端发送语句

Quit ：正在退出

Shutdown ：正在关闭服务器

Time ：表示该线程处于当前状态的时间，单位是秒

State ：线程状态

Updating ：正在搜索匹配记录，进行修改

Sleeping ：正在等待客户端发送新请求

Starting ：正在执行请求处理

Checking table ：正在检查数据表

Closing table : 正在将表中数据刷新到磁盘中

Locked ：被其他查询锁住了记录

Sending Data ：正在处理 Select 查询，同时将结果发送给客户端

Info ：一般记录线程执行的语句，默认显示前 100 个字符。想查看完整的使用 show full

processlist;

②查询缓存（ Cache&Buffffer ），这是 MySQL 的一个可优化查询的地方，如果开启了查询缓存且在

查询缓存过程中查询到完全相同的 SQL 语句，则将查询结果直接返回给客户端；如果没有开启查询

缓存或者没有查询到完全相同的 SQL 语句则会由解析器进行语法语义解析，并生成 “ 解析树 ” 。

缓存 Select 查询的结果和 SQL 语句

执行 Select 查询时，先查询缓存，判断是否存在可用的记录集，要求是否完全相同（包括参

数值），这样才会匹配缓存数据命中。

即使开启查询缓存，以下 SQL 也不能缓存

查询语句使用 SQL_NO_CACHE

查询的结果大于 query_cache_limit 设置

查询中有一些不确定的参数，比如 now()

show variables like '%query_cache%'; // 查看查询缓存是否启用，空间大小，限制等

show status like 'Qcache%'; // 查看更详细的缓存参数，可用缓存空间，缓存块，缓存多少等 ③解析器（ Parser ）将客户端发送的 SQL 进行语法解析，生成 " 解析树 " 。预处理器根据一些 MySQL

规则进一步检查 “ 解析树 ” 是否合法，例如这里将检查数据表和数据列是否存在，还会解析名字和别

名，看看它们是否有歧义，最后生成新的 “ 解析树 ” 。

④查询优化器（ Optimizer ）根据 “ 解析树 ” 生成最优的执行计划。 MySQL 使用很多优化策略生成最

优的执行计划，可以分为两类：静态优化（编译时优化）、动态优化（运行时优化）。

等价变换策略

5=5 and a>5 改成 a > 5

a < b and a=5 改成 b>5 and a=5

基于联合索引，调整条件位置等

优化 count 、 min 、 max 等函数

InnoDB 引擎 min 函数只需要找索引最左边

InnoDB 引擎 max 函数只需要找索引最右边

MyISAM 引擎 count(*) ，不需要计算，直接返回

提前终止查询

使用了 limit 查询，获取 limit 所需的数据，就不在继续遍历后面数据

in 的优化

MySQL 对 in 查询，会先进行排序，再采用二分法查找数据。比如 where id in (2,1,3) ，变

成 in (1,2,3)

⑤查询执行引擎负责执行 SQL 语句，此时查询执行引擎会根据 SQL 语句中表的存储引擎类型，以

及对应的 API 接口与底层存储引擎缓存或者物理文件的交互，得到查询结果并返回给客户端。若开

启用查询缓存，这时会将 SQL 语句和结果完整地保存到查询缓存（ Cache&Buffffer ）中，以后若有

相同的 SQL 语句执行则直接返回结果。

如果开启了查询缓存，先将查询结果做缓存操作

返回结果过多，采用增量模式返回

第 3 节 MySQL 存储引擎

存储引擎在 MySQL 的体系架构中位于第三层，负责 MySQL 中的数据的存储和提取，是与文件打交道的

子系统，它是根据 MySQL 提供的文件访问层抽象接口定制的一种文件访问机制，这种机制就叫作存储引

擎。

使用 show engines 命令，就可以查看当前数据库支持的引擎信息。

在 5.5 版本之前默认采用 MyISAM 存储引擎，从 5.5 开始采用 InnoDB 存储引擎。 InnoDB ：支持事务，具有提交，回滚和崩溃恢复能力，事务安全

MyISAM ：不支持事务和外键，访问速度快

Memory ：利用内存创建表，访问速度非常快，因为数据在内存，而且默认使用 Hash 索引，但是

一旦关闭，数据就会丢失

Archive ：归档类型引擎，仅能支持 insert 和 select 语句

Csv ：以 CSV 文件进行数据存储，由于文件限制，所有列必须强制指定 not null ，另外 CSV 引擎也不

支持索引和分区，适合做数据交换的中间表

BlackHole: 黑洞，只进不出，进来消失，所有插入数据都不会保存

Federated ：可以访问远端 MySQL 数据库中的表。一个本地表，不保存数据，访问远程表内容。

MRG_MyISAM ：一组 MyISAM 表的组合，这些 MyISAM 表必须结构相同， Merge 表本身没有数据，

对 Merge 操作可以对一组 MyISAM 表进行操作。

3.1 InnoDB 和 MyISAM 对比

InnoDB 和 MyISAM 是使用 MySQL 时最常用的两种引擎类型，我们重点来看下两者区别。

事务和外键

InnoDB 支持事务和外键，具有安全性和完整性，适合大量 insert 或 update 操作

MyISAM 不支持事务和外键，它提供高速存储和检索，适合大量的 select 查询操作

锁机制

InnoDB 支持行级锁，锁定指定记录。基于索引来加锁实现。

MyISAM 支持表级锁，锁定整张表。

索引结构

InnoDB 使用聚集索引（聚簇索引），索引和记录在一起存储，既缓存索引，也缓存记录。

MyISAM 使用非聚集索引（非聚簇索引），索引和记录分开。

并发处理能力

MyISAM 使用表锁，会导致写操作并发率低，读之间并不阻塞，读写阻塞。

InnoDB 读写阻塞可以与隔离级别有关，可以采用多版本并发控制（ MVCC ）来支持高并发

存储文件

InnoDB 表对应两个文件，一个 .frm 表结构文件，一个 .ibd 数据文件。 InnoDB 表最大支持 64TB ；

MyISAM 表对应三个文件，一个 .frm 表结构文件，一个 MYD 表数据文件，一个 .MYI 索引文件。从

MySQL5.0 开始默认限制是 256TB 。 适用场景

MyISAM

不需要事务支持（不支持）

并发相对较低（锁定机制问题）

数据修改相对较少，以读为主

数据一致性要求不高

InnoDB

需要事务支持（具有较好的事务特性）

行级锁定对高并发有很好的适应能力

数据更新较为频繁的场景

数据一致性要求较高

硬件设备内存较大，可以利用 InnoDB 较好的缓存能力来提高内存利用率，减少磁盘 IO

总结

两种引擎该如何选择？

是否需要事务？有， InnoDB

是否存在并发修改？有， InnoDB

是否追求快速查询，且数据修改少？是， MyISAM

在绝大多数情况下，推荐使用 InnoDB

扩展资料：各个存储引擎特性对比 3.2 InnoDB 存储结构

从 MySQL 5.5 版本开始默认使用 InnoDB 作为引擎，它擅长处理事务，具有自动崩溃恢复的特性，在日

常开发中使用非常广泛。下面是官方的 InnoDB 引擎架构图，主要分为内存结构和磁盘结构两大部分。

一、 InnoDB 内存结构 内存结构主要包括 Buffffer Pool 、 Change Buffffer 、 Adaptive Hash Index 和 Log Buffffer 四大组件。

Buffffer Pool ：缓冲池，简称 BP 。 BP 以 Page 页为单位，默认大小 16K ， BP 的底层采用链表数

据结构管理 Page 。在 InnoDB 访问表记录和索引时会在 Page 页中缓存，以后使用可以减少磁

盘 IO 操作，提升效率。

Page 管理机制

Page 根据状态可以分为三种类型：

free page ： 空闲 page ，未被使用

clean page ：被使用 page ，数据没有被修改过

dirty page ：脏页，被使用 page ，数据被修改过，页中数据和磁盘的数据产生了不

一致

针对上述三种 page 类型， InnoDB 通过三种链表结构来维护和管理

free list ：表示空闲缓冲区，管理 free page

flflush list ：表示需要刷新到磁盘的缓冲区，管理 dirty page ，内部 page 按修改时间

排序。脏页即存在于 flflush 链表，也在 LRU 链表中，但是两种互不影响， LRU 链表负

责管理 page 的可用性和释放，而 flflush 链表负责管理脏页的刷盘操作。

lru list ：表示正在使用的缓冲区，管理 clean page 和 dirty page ，缓冲区以

midpoint 为基点，前面链表称为 new 列表区，存放经常访问的数据，占 63% ；后

面的链表称为 old 列表区，存放使用较少数据，占 37% 。

改进型 LRU 算法维护

普通 LRU ：末尾淘汰法，新数据从链表头部加入，释放空间时从末尾淘汰

改性 LRU ：链表分为 new 和 old 两个部分，加入元素时并不是从表头插入，而是从中间

midpoint 位置插入，如果数据很快被访问，那么 page 就会向 new 列表头部移动，如果

数据没有被访问，会逐步向 old 尾部移动，等待淘汰。

每当有新的 page 数据读取到 buffffer pool 时， InnoDb 引擎会判断是否有空闲页，是否足

够，如果有就将 free page 从 free list 列表删除，放入到 LRU 列表中。没有空闲页，就会

根据 LRU 算法淘汰 LRU 链表默认的页，将内存空间释放分配给新的页。

Buffffer Pool 配置参数

show variables like '%innodb_page_size%'; // 查看 page 页大小

show variables like '%innodb_old%'; // 查看 lru list 中 old 列表参数

show variables like '%innodb_buffffer%'; // 查看 buffffer pool 参数

建议：将 innodb_buffffer_pool_size 设置为总内存大小的 60%-80% ，

innodb_buffffer_pool_instances 可以设置为多个，这样可以避免缓存争夺。

Change Buffffer ：写缓冲区，简称 CB 。在进行 DML 操作时，如果 BP 没有其相应的 Page 数据，

并不会立刻将磁盘页加载到缓冲池，而是在 CB 记录缓冲变更，等未来数据被读取时，再将数

据合并恢复到 BP 中。

ChangeBuffffer 占用 BufffferPool 空间，默认占 25% ，最大允许占 50% ，可以根据读写业务量来

进行调整。参数 innodb_change_buffffer_max_size;

当更新一条记录时，该记录在 BufffferPool 存在，直接在 BufffferPool 修改，一次内存操作。如

果该记录在 BufffferPool 不存在（没有命中），会直接在 ChangeBuffffer 进行一次内存操作，不

用再去磁盘查询数据，避免一次磁盘 IO 。当下次查询记录时，会先进性磁盘读取，然后再从

ChangeBuffffer 中读取信息合并，最终载入 BufffferPool 中。

写缓冲区，仅适用于非唯一普通索引页，为什么？

如果在索引设置唯一性，在进行修改时， InnoDB 必须要做唯一性校验，因此必须查询磁盘，

做一次 IO 操作。会直接将记录查询到 BufffferPool 中，然后在缓冲池修改，不会在

ChangeBuffffer 操作。 Adaptive Hash Index ：自适应哈希索引，用于优化对 BP 数据的查询。 InnoDB 存储引擎会监

控对表索引的查找，如果观察到建立哈希索引可以带来速度的提升，则建立哈希索引，所以

称之为自适应。 InnoDB 存储引擎会自动根据访问的频率和模式来为某些页建立哈希索引。

Log Buffffer ：日志缓冲区，用来保存要写入磁盘上 log 文件（ Redo/Undo ）的数据，日志缓冲

区的内容定期刷新到磁盘 log 文件中。日志缓冲区满时会自动将其刷新到磁盘，当遇到 BLOB

或多行更新的大事务操作时，增加日志缓冲区可以节省磁盘 I/O 。

LogBuffffer 主要是用于记录 InnoDB 引擎日志，在 DML 操作时会产生 Redo 和 Undo 日志。

LogBuffffer 空间满了，会自动写入磁盘。可以通过将 innodb_log_buffffer_size 参数调大，减少

磁盘 IO 频率

innodb_flflush_log_at_trx_commit 参数控制日志刷新行为，默认为 1

0 ： 每隔 1 秒写日志文件和刷盘操作（写日志文件 LogBuffffer-->OS cache ，刷盘 OS

cache--> 磁盘文件），最多丢失 1 秒数据

1 ：事务提交，立刻写日志文件和刷盘，数据不丢失，但是会频繁 IO 操作

2 ：事务提交，立刻写日志文件，每隔 1 秒钟进行刷盘操作

二、 InnoDB 磁盘结构

InnoDB 磁盘主要包含 Tablespaces ， InnoDB Data Dictionary ， Doublewrite Buffffer 、 Redo Log

和 Undo Logs 。

表空间（ Tablespaces ）：用于存储表结构和数据。表空间又分为系统表空间、独立表空间、

通用表空间、临时表空间、 Undo 表空间等多种类型；

系统表空间（ The System Tablespace ）

包含 InnoDB 数据字典， Doublewrite Buffffer ， Change Buffffer ， Undo Logs 的存储区

域。系统表空间也默认包含任何用户在系统表空间创建的表数据和索引数据。系统表空

间是一个共享的表空间因为它是被多个表共享的。该空间的数据文件通过参数

innodb_data_fifile_path 控制，默认值是 ibdata1:12M:autoextend( 文件名为 ibdata1 、

12MB 、自动扩展 ) 。

独立表空间（ File-Per-Table Tablespaces ）

默认开启，独立表空间是一个单表表空间，该表创建于自己的数据文件中，而非创建于

系统表空间中。当 innodb_fifile_per_table 选项开启时，表将被创建于表空间中。否则，

innodb 将被创建于系统表空间中。每个表文件表空间由一个 .ibd 数据文件代表，该文件

默认被创建于数据库目录中。表空间的表文件支持动态（ dynamic ）和压缩

（ commpressed ）行格式。

通用表空间（ General Tablespaces ）

通用表空间为通过 create tablespace 语法创建的共享表空间。通用表空间可以创建于

mysql 数据目录外的其他表空间，其可以容纳多张表，且其支持所有的行格式。

CREATE TABLESPACE ts1 ADD DATAFILE ts1.ibd Engine=InnoDB; // 创建表空

间 ts1

CREATE TABLE t1 (c1 INT PRIMARY KEY) TABLESPACE ts1; // 将表添加到 ts1

表空间

撤销表空间（ Undo Tablespaces ）

撤销表空间由一个或多个包含 Undo 日志文件组成。在 MySQL 5.7 版本之前 Undo 占用的

是 System Tablespace 共享区，从 5.7 开始将 Undo 从 System Tablespace 分离了出来。

InnoDB 使用的 undo 表空间由 innodb_undo_tablespaces 配置选项控制，默认为 0 。参

数值为 0 表示使用系统表空间 ibdata1; 大于 0 表示使用 undo 表空间 undo_001 、

undo_002 等。

临时表空间（