MySQL 体系架构

一. MySQL 分支与变种

MySQL变种，主流有三个：Drizzle，MariaDB，Percona Server。

它们都有活跃的用户社区和一些商业支持，均由独立的服务供应商支持。

1. Drizzle

Drizzle是MySQL真正的分支，而且完全开源的产品。而非只是个变种或增强版本。它并不与MySQL兼容，不能简单的将MySQL后端替换为Drizzle。

Drizzle和MySQL有很大差别，进行了一些重大更改，甚至SQL语法的变化都非常大，设计目标之一是提供一种出色的解决方案来解决高可用问题。在是实现上，Drizzle清楚了一些表现不佳和不必要的功能，将很多代码充血，对它们进行优化，甚至将语言从C换成了C++。

此外，Drizzle另一个设计目标哦能很好的适应具有大量内容的多核服务器，运行Linux的64位机器，云计算使用的服务器，托管网站的服务器和每分钟接收数以万计点率的服务器并且大幅度的削减服务器成本。

2. MariaDB

在Sun收购MySQL后，Monty Widenius（MySQL创建者），因不认同MySQL开发流程离开Sun。他成立了Monty程序公司，创立了MariaDB。

MariaDB的目标是社区开发，Bug修复和许多的新特性。可以将MariaDB视为MySQL的扩展集，它不仅提供MySQL的所有的功能，还提供其他功能。MariaDB是原版MySQL的超集，因此已有的系统不需要任何修改就可以运行。

诸如Google，Facebook，维基百科等公司或者网站所使用了MariaDB，不过Monty公司不是以盈利为目的，而是由产品驱动的，这可能带来问题，因为没有盈利手段，公司不一定长久维持下去。

3. Percona Server

由领先的MySQL咨询公司Percona发布，Percona公司的口是The Database Performance Experts，Percona的创始人也是《高性能MySQL》书的作者。

Percona Server是个MySQL向后兼容的替代品，它尽可能不改变SQL语法，客户端 /服务器协议和磁盘 上 的文件格式。任何运行在MySQL上的都可以运行在Percona Server上而不需要修改。切换到Percona Server只需关闭MySQL和启动Percona，2个步骤，不需要导出和 重新导入数据。

Percona Server有三个主要的目标

1. 透明，增加允许用户更紧密查看服务器内部信息和行为的方法。比如慢查询日志特别增加详细信息；
2. 性能。Percona Server 包含许多性能和可扩展方面改进，还加强了性能的可预测性和稳定性。其中主要集中于InnoDB。
3. 操作灵活性，Percona Server使操作人员和系统管理员在让MySQL作为Percona Server架构的一部分，从而可以可靠并稳定运行时提供很多便利。

一般来说，Percona Server 中的许多特性会在后来的标准MySQL出现。

国内阿里就运行了上千个Percona Server实例。

二. MySQL的替代

1. Postgre SQL

PostgreSQL称自己是世界上最先进的开源数据库，同时也是一专多长的全栈数据库。最初是1985年在加利福尼亚大学伯克利分校开发的。

PostgreSQL的稳定性极强，在崩溃，断电之类的灾难场景下依然可以保证数据的正确。在高并发读写，负载逼近极限下，PostgreSQL的性能指标仍可以维持双曲线甚至对数曲线，到顶峰之后不再下降，表现的非常稳定，而MysQL明显出现一个波峰后下滑。

PostgreSQL多年来在GIS（地理位置）领域处于优势地位，因为它有丰富 的几何类型，实际上不止步于几何类型，PostgreSQL有大量的字典，数组，bitmap等数据类型 ，相比之下MySQL就差很多。

所以总的来说，PostgreSQL更学术化一些，在绝对需要可靠性和 数据完整性的时候，PostgreSQL是更好的选择。但是从商业支持，文档资料，易用性，第三方支持来说，MySQL无疑更好些。

2. SQLite

SQLite是世界上部署最广泛的数据库引擎，为物联网（IOT）下的数据库首选，并且是手机，PDA，甚至MP3播放器下的首选。SQLite代码占用空间小，并且不要数据库管理员的维护。SQLite没有单独的服务进程，提供的事务也基本符合ACID，但同时，简单也就意味着功能和性能受限。

三. MySQL 体系架构

可看出MySQL是由连接池，管理工具和服务，SQL接口，解析器，优化器，缓存，存储引擎，文件系统组成。

1. 连接池：由于每次建立需要耗费很多时间，连接池的作用就是将这些连接缓存下来，下次可以直接用已经建立好的连接，提升服务器性能。
2. 管理工具和服务：系统管理和控制工具，例如备份恢复，MySQL复制，集群等。
3. SQL接口：接受用户的SQL命令，并且返回用户需要查询的结果。比如select ... from就是调用SQL接口
4. 解析器：SQL命令传递到解析起的时候，会被解析起验证和解析。主要功能：将SQL语句分解成数据结构，后续步骤的传递和处理就是基于这个结构的。
5. 优化器：查询优化器，SQL语句在查询之前会使用查询优化器对查询进行优化。
6. 缓存器：查询缓存，如果查询缓存有命中的查询结果，查询语句就可以直接去查询缓存中数据。这个缓存机制是有一些列小缓存组成的，啊比如表缓存，记录缓存，key缓存，权限缓存等。
7. 存储引擎（看后续章节）
8. 文件系统（看后续章节）

1.连接层

当MySQL启动（MySQL服务器就是一个进程），等待客户端连接，每一个客户端连接起扭曲，服务器进程会创建一个线程专门处理与这个客户端的交互。当客户端与服务器断开后，不会立即撤销线程，只会把他缓存起来等待下一个客户端请求连接，将其分配给该客户端。每个线程独立，拥有各自的内存处理空间。

查看最大连接数

show variables like 'max_connections';

连接到服务器后，会对客户端进行验证（用户名，IP，密码进行验证），连接成功后，还要验证是否具有执行某个特定查询等权限（例如，是否允许客户端对某个数据库某个表的权限）。

2 Server层（SQL处理层）

功能：

1. SQL语句解析，优化，缓存查询。
2. MySQL内置函数的实现
3. 跨存储引擎功能：每个引擎都需要提供功能（引擎需对外提供接口），例如：存储过程，触发器，视图等。

SQL处理等执行流程：

1. 若是select语句，查询缓存是否命中。
2. 解析查询：创建一个解析树（内部数据结构），用来SQL语句的语义和语法解析。
3. 优化：优化SQL语句，列如重写查询，表的读取顺序，选择需要的索引。这一阶段用户是可以查询的，查询服务器优化器是如何进行优化的，便于用户重构查询和修改相关配置，达到最优化。这一阶段还涉及到存储引擎，优化器会询问存储引擎。比如某个操作的开销信息，是否对特定索引you查询优化等。

⭐️缓存

-- 缓存开启配置（默认关闭）
show variables like 'query_cache_type';-- 缓存大小（默认1M）
show variables like 'query_cache_size';-- 修改缓存开启配置，需在my.cnf里进行修改
-- 执行会报错
set global query_cache_type = 'on';

缓存在生产环境一般是不开启的，除非经常有sql一模一样的查询。

缓存严格要求2次sql请求要完全一样。sql语句，连接的数据库，协议版本，字符集等因素不一样，都会导致缓存失效。

从8.0，MySQL不在使用缓存。

MySQL查询缓存是查询结果缓存，它将SEL开头的查询与哈希表进行比较，如果匹配，则返回上一次查询结果，进行匹配时，查询必须逐字节匹配，如select * from e1;不等于SELECT * FROM e1;。

此外，一些不确定的查询结果无法被缓存，任何对表修改都会导致这些表的所有缓存失效。缓存的理想方案是只读，特别是需要检查数百万行后仅返回数行的复杂查询。如果你的查询符合这样一个特点，那可以打开缓存。

缓存效果取决于缓存命中率，只有命中缓存的查询才能有改善，因此无法预测其性能。查询缓存的另一个大问题是它受到单个互斥锁的保护。在具有多个内核的服务器上，大量查询会导致大量的互斥锁争用。通过基准测试，大多数工作负载最好禁用查询缓存。官方阐述：造成的问题比它解决问题多的多，弊大于利就直接砍掉。

3. 存储引擎层

从之前体系结构图可发现，MySQL数据库区别于其他数据库的最重要的一个特点是支持插件式的表存储引擎。MySQL插件式的存储引擎架构提供了一系列标准的管理和服务支持，这些标准与存储引擎本身无关。SQL分析器和优化器是每个数据库本身必须的，而存储引擎是底层物理结构和实际文件读写的实现，每个存储引擎开发着可以按照自己的意愿来进行开发。需要特别注意，存储引擎是基于表的，而不是数据库。

插件式存储引擎的好处：

1. 每个存储引擎各有个性化的特点，可根据具体应用简历不同存储引擎表。
2. MySQL数据库开元特性，用户可根据MySQL预定义的存储引擎接口便携自己的存储引擎。
3. 用户对某一种存储引擎的性能或功能不满意，可通过修改源码来获得想要的特性。

由于MySQL数据开源的特性，存储引擎可分为MySQL官方存储引擎和三方存储引擎。有些三方存储引擎很强大，如InnoDB存储引擎（最早是第三方存储引擎，后被Oracle收购），其应用就极其广泛，甚至MySQL数据库OLTP（Online Transaction Processing 在线事务处理）应用中使用的最广泛的存储引擎。

1）MySQL官方存储引擎概要

⭐️InnoDB存储引擎

InnoDB是MySQL的默认事务型存储引擎，也是最重要，使用广泛的存储引擎。它被设计用来处理大量的短期（short-lived）事务，短期事务大部分情况是正常提交的，很少会被回滚。InnoDB的性能和自动崩溃恢复特性，使得它在非事务型存储的需求中也很流行。除非有非常特别的原因需要使用其他存储引擎，否则应该优先考虑InnoDB存储引擎，InnodB引擎是一个非常好的值得花最多的时间去深入学习的对象，收益肯定比时间平均花在每个存储引擎的学习上要高得多。所以InnodB是重点学习对象。

⭐️MyISAM存储引擎

在MySQL5.1及之前版本，MyISAM是默认的存储引擎。MyISAM提供大量的特性，包括全文索引，压缩，空间函数（GIS）等，但MyISAM不支持事务和行级锁，而且有一个毫无疑问的缺陷是崩溃后无法安全恢复。尽管MyISAM存储引擎不支持事务，不支持崩溃后的安全恢复。对于只读的数据，或者表比较小，可以忍受修复（repair）操作，则依然可以继续使用MyISAM。但MyISAM对整张表加锁，而不是针对行。读取时会对需要读到的所有表加共享锁，写入时则对整张表加入排他锁。MyISAM很容易因为表锁的问题导致典型的性能问题。

⭐️Mrg_MyISAM存储引擎

Merge存储引擎，是一组MyIsam的组合，也就是说，他将MyIsam引擎的多个表聚合起来，但是他的内部没有数据，真正的数据依然是MyIsam引擎的表中，但是可以直接进行查询、删除更新等操作。

⭐️Achive存储引擎

Archive存储引擎只支持INSERT和SELECT操作，在MySQL 5.1之前也不支持索引。Archive引擎会缓存所有的写并利用zlib对插入的行进行压缩，所以比MyISAM表的磁盘I/O更少。但是每次SELECT查询都需要执行全表扫描。所以Archive表适合日志和数据采集类应用，这类应用做数据分析时往往需要全表扫描。或者在一些需要更快速的INSERT操作的场合下也可以使用。Archive引擎不是一个事务型的引擎，而是一个针对高速插入和压缩做了优化的简单引擎。

⭐️Blackhole存储引擎

Blackhole引擎没有实现任何的存储机制，它会丢弃所有插入的数据，不做任何保存。但是服务器会记录Blackhole表的日志，所以可以用于复制数据到备库，或者只是简单地记录到日志。这种特殊的存储引擎可以在一些特殊的复制架构和日志审核时发挥作用。但这种引擎在应用方式上有很多问题，因此并不推荐。

⭐️CSV存储引擎

CSV引擎可以将普通的CSV文件(逗号分割值的文件）作为MySQL的表来处理，但这种表不支持索引。CSV引擎可以在数据库运行时拷入或者拷出文件。可以将Excel等的数据存储为CSV文件，然后复制到MySQL数据目录下，就能在MySQL 中打开使用。同样，如果将数据写入到一个CSV引擎表，其他的外部程序也能立即从表的数据文件中读取CSV格式的数据。因此CSV引擎可以作为一种数据交换的机制，非常有用。

⭐️Federated存储引擎

Federated引擎是访问其他MySQL服务器的一个代理，它会创建一个到远程MySQL服务器的客户端连接，并将查询传输到远程服务器执行，然后提取或者发送需要的数据。最初设计该存储引擎是为了和企业级数据库如Microsoft SQL Server和 Oracle的类似特性竞争的，可以说更多的是一种市场行为。尽管该引擎看起来提供了一种很好的跨服务器的灵活性，但也经常带来问题，因此默认是禁用的。

⭐️Memory存储引擎

如果需要快速地访问数据，并且这些数据不会被修改，重启以后丢失也没有关系，那么使用Memory表(以前也叫做HEAP表）是非常有用的。Memory表至少比MyISAM 表要快一个数量级，因为每个基于MEMORY存储引擎的表实际对应一个磁盘文件。该文件的文件名与表名相同，类型为frm类型。该文件中只存储表的结构。而其数据文件，都是存储在内存中，这样有利于数据的快速处理，提高整个表的效率，不需要进行磁盘I/O。所以Memory表的结构在重启以后还会保留，但数据会丢失。

Memory表支持 Hash索引，因此查找操作非常快。虽然Memory表的速度非常快，但还是无法取代传统的基于磁盘的表。Memroy表是表级锁，因此并发写入的性能较低。它不支持BLOB或TEXT类型的列，并且每行的长度是固定的，所以即使指定了VARCHAR 列，实际存储时也会转换成CHAR，这可能导致部分内存的浪费。

⭐️NDB集群存储引擎

使用MySQL服务器、NDB集群存储引擎，以及分布式的、share-nothing 的、容灾的、高可用的NDB数据库的组合，被称为MySQL集群（(MySQL Cluster)。

2）第三方引擎

⭐️Persona的XtraDB存储引擎

基于InnoDB引擎的一个改进版本，已经包含在Percona Server和 MariaDB中，它的改进点主要集中在性能、可测量性和操作灵活性方面。XtraDB可以作为InnoDB的一个完全的替代产品，甚至可以兼容地读写InnoDB的数据文件，并支持InnoDB的所有查询。

⭐️TokuDB存储引擎

使用了一种新的叫做分形树(Fractal Trees)的索引数据结构。该结构是缓存无关的，因此即使其大小超过内存性能也不会下降，也就没有内存生命周期和碎片的问题。TokuDB是一种大数据（Big Data)存储引擎，因为其拥有很高的压缩比，可以在很大的数据量上创建大量索引。现在该引擎也被Percona公司收购。

分形树，是一种写优化的磁盘索引数据结构。 分形树的写操作（Insert/Update/Delete）性能比较好，同时它还能保证读操作近似于B+树的读性能。据测试结果显示， TokuDB分形树的写性能优于InnoDB的B+树，读性能略低于B+树。分形树核心思想是利用节点的MessageBuffer缓存更新操作，充分利用数据局部性原理，将随机写转换为顺序写，这样极大的提高了随机写的效率。

⭐️Infobright

MySQL默认是面向行的，每一行的数据是一起存储的，服务器的查询也是以行为单位处理的。而在大数据量处理时，面向列的方式可能效率更高，比如HBASE就是面向列存储的。

Infobright是最有名的面向列的存储引擎。在非常大的数据量（数十TB)时，该引擎工作良好。Infobright是为数据分析和数据仓库应用设计的。数据高度压缩，按照块进行排序，每个块都对应有一组元数据。在处理查询时，访问元数据可决定跳过该块，甚至可能只需要元数据即可满足查询的需求。但该引擎不支持索引，不过在这么大的数据量级，即使有索引也很难发挥作用，而且块结构也是一种准索引 (quasi-index)。Infobright需要对MySQL服务器做定制，因为一些地方需要修改以适应面向列存储的需要。如果查询无法在存储层使用面向列的模式执行，则需要在服务器层转换成按行处理，这个过程会很慢。Infobright有社区版和商业版两个版本。

3）选择合适的引擎

如果用到某些InnoDB存储引擎不具备的特性，并且没有其他方式替代，否则InnoDB存储引擎是首选。

比如，MySQL中只有MyISAM支持地理空间搜索。

如果不需要用到InnoDB的特性，同时其他存储引擎的特性能够更好地满足需求，也可以考虑。如，不在乎扩展能力和并发能力，也不在乎数据崩溃数据丢失的问题。却对InnoDB的空间占用过多的比较敏感，这种场合适合选MyISAM。

除非万不得已，否则建议不要混合使用多种存储引擎，否则会带来一些列复杂的问题，以及一些潜在的bug和边界问题。存储引擎层和服务器层的交互已经比较复杂，更不用说混合多个存储引擎了。而且混合存储对一致性备份和服务器参数配置带来了困难。

4）表引擎的转换

⭐️alter table

上述语法可以适用任何存储引擎。但需要执行很长时间，在实现上，MySQL会按行将数据从原表复制到一张新表，在复制期间可能会消耗系统的所有IO能力，同时在原表上会加上读锁。所以在繁忙的表上执行此操作要特别小心。

alter table a engine = InnoDB;

⭐️导出与导入

还可使用mysqldump工具将数据导出到文件，然后修改文件中create table语句的存储引擎选项，并修改表名为临时表名（同一个库不能存相同的表），即使使用的是不同存储引擎。

⭐️create和select

-- 创建存储引擎表,从b表进行复制表结构
create table myisam_test like b;
-- 修改存储引擎
alter table myisam_test engine =MyISAM;
-- 数据同步
insert into myisam_test select * from b;

5）检查MySQL存储引擎

查看MySQL提供的存储引擎类型

show engines;

查看MySQL的默认存储引擎

show variables like '%storage_engine%';

6）MyISAM和InnoDB比较

维度	MyISAM	InnoDB
主外键	不支持	支持
事务	不支持	支持
行表锁	表锁	行锁
缓存	只缓存索引	缓存索引和真实数据，对内存要求高，而且内存大小对性能有决定性影响
表空间	小	大
关注点	性能	事务
默认安装	是	是

四. MySQL的目录和文件

1. bin 目录

MySQL的安装目录bin，存放着许多执行文件。都是与服务器程序和客户端程序相关的。

1）启动MySQL服务器程序

在unix系统中启动MySQL服务器程序的可执行文件有很多

⭐️mysqld

代表着MySQL服务器程序，运行这个可执行文件就可直接启动一个服务器进程。但不常用

⭐️mysql_safe

mysqld_safe是一个启动脚本，它会简介调用mysqld，而且还顺便启动了另外一个监控进程，这个监控进程在服务器进程挂了的时候，可以帮助重启它。

使用mysqld_safe启动服务器程序时，它将服务器程序的出错信息和其他诊断信息重定向到某个文件中，产生出错日志，方便查找出错原因。

⭐️mysql.server

mysql.server是一个启动脚本，它会间接调用mysqld_safe，在调用mysql.server时在后边指定start参数就可启动服务器。

-- 开启
mysql.server start;-- 关闭
mysql.server stop;

需要注意的是，这个mysql.server文件其实是一个链接文件，它的实际文件是support-files/mysql.server，在bin目录找不到，到support-files下去找，也可用ln命令在bin下创建个链接。

⭐️mysqld_multi

一台计算机可运行多个服务器实例，运行多个MySQL服务器进程。

mysql_multi可执行文件可对每一个服务器进程启动或停止进行监控。

2）客户端程序

启动MySQL服务器后，可通过客户端程序进行连接服务器。

bin目录下有许多客户端程序，比如mysqladmin，mysqldump，mysqlcheck等。

我们常用的可执行文件mysql，通过这个可执行文件可让我们和服务器程序进行交互（发送请求，接收服务器处理结果）。

mysqladmin执行管理操作的工具，检查服务器配置，当前运行状态，创建，删除数据库，设置新密码。

mysqldump数据库逻辑备份程序。

mysqlbackup备份数据表，整个数据库，所有数据库，一般来说mysqldump备份，mysql还原。

2. 启动选项和参数

1）配置参数文件

MySQL实例启动时，数据库会先去读一个配置参数文件，用来寻找数据库各种文件所在位置以及指定某些初始化参数。这些参数通常定义了某种内存结构有多大等。在默认情况下，MySQL实例会按顺序在指定的位置进行读取。

可通过mysql --help | grep my.cnf来寻找。

启动MySQL时，也可指定配置文件（非yum安装）

./bin/mysqld_safe --defaults-file=/**/**/my.cnf# 查看配置信息
ps -ef ｜ grep mysqld

MySQL数据库参数文件的作用和Oracle数据库的参数文件极其类似，不同的是，Oracle实例在启动时若找不到参数文件，是不能进行装载（mount）操作的。

MySQL略有不同，MySQL实例可以不需要参数文件，这时所有的参数值取决于编译MySQL时指定默认值和源代码中指定参数的默认值。

MySQL数据库的参数文件是以文本方式进行存储的。可直接通过一些常用的文本编辑软件进行参数修改。

2）参数的查看和修改

通过命令show variables查看数据库中的所有参数，也可通过like来过滤参数名，前面查找数据库引擎已经展示了，从MySQL5.1版本开始，还可通过information_shcema架构下的global_variables视图进行查找

但更推荐使用命令show variables，使用更简单，各版本数据库都支持。

全局配置参数

MySQL数据库中的参数分类：

1. 动态(dynamic)参数：MySQL实例运行时，进行更改。
2. 静态(static)参数：实例生命周期内不得进行更改。

MySQL数据库作用范围分类：

1. 全局变量（GLOBAL）：影响服务器的整体操作。
2. 会话变量（SESSION/LOCAL）：影响某个客户端连接操作。

通过SET命令对动态参数修改

set [global|session] 参数名=值;set [@@global.|@@session.]参数名 = 值;如
set read_buffer_size=524288;
set session read_buffer_size=524288;
set @@global.read_buffer_size=524288;

MySQL所有动态变量可修改范围，可参考MySQL官方手册Dynamic System Variables。

对于静态变量修改，会得到下面的错误

3. 数据目录

InnoDB，MyISAM存储引擎是把表存储在文件系统上，当我们想读取数据时，这些存储引擎会从文件系统中国呢把数据读出来返回给我们，当我们想写入数据的时候，这些存储引擎会把这些数据写到文件系统中。

1）MySQL数据目录

MySQL数据存在的位置，是通过datadir变量查看，如果想更改位置，需在my.cnf进行更改，并重新启动mysql。

show variables like 'datadir';

2）数据目录内容

MySQL运行时会产生创建数据库，表，视图和触发器等用户数据。

除此之外，为了程序更好的运行，MySQL会创建一些其他额外的数据。

3）数据库在文件系统中的表示

create database practice charset = utf8;

当创建一个数据库时，文件系统会这么处理？

每个数据库都对应数据目录下的一个子目录，或者说对应一个文件夹。创建新的数据库，MySQL会做这两件事

1. 在数据目录下创建一个数据库名相同的子目录（文件夹）。

2. 在刚创建的目录下，在MySQL8.0之前还会创建db.opt文件，这个文件包含了该数据库的各种属性，比方说数据库字符集，比较规则等。

   (.frm, .par, .trn, .isl, .db.opt)在MySQL8都不存在了)

除了information_schema系统数据库外，剩下的数据库都有对应的子目录。information_schema比较特殊，后面会提及。

4）表在文件系统中的展示

数据插入，是以记录形式插入表中，表中信息分为2种：

1. 表的结构定义
2. 表中的数据

表结构是指表名称，列的个数，每个列的数据列星，约束条件，索引，使用的字符集，比较规则等各种信息。InnoDB和MyISAM在数据目录下对应的数据库子目录下创建了一个专门用于描述表结构文件，文件名是：表名.ibd（二进制格式存储）

如：

切换到pactice系统目录下查看

5）InnoDB如何存储表数据

InnoDB到数据会放在一个表空间或者文件空间（table spaces或file space）。

这个表空间是一个抽象概念，它可对应文件系统上一个或多个真实文件（不同表空间对应文件数量不同）。每一个表空间可被划分为很多个页，我们的表数据就存放在某个表空间下的某些页里。表空间分3种类型。

⭐️系统表空间（system tablespace）

系统表空间对应文件系统上一个或多个实际文件，默认情况下，InnoDB会在数据目录下创建一个名为ibdatal（在数据目录下），大小为12M，这个文件的作用是对应的系统表空间在文件系统上的表示。

文件是所谓的自扩展文件，当不够用时，会动态扩容文件。

如果想让表空间对应文件系统上多个实际文件，可在MySQL启动时配置对应的文件路径以及它们的大小。也可把系统表空间对应文件路径不配置到数据目录下，甚至可配置到单独的磁盘分区上。

需要注意的点是，在MysQL服务器中，系统表空间只有一份。从MySQL5.5.7到MySQL5.6.6的各个版本中，我们表中的数据都会默认存储到这个系统表空间

⭐️独立表空间（file-per-table tablespace）

在MySQL5.6.6以及之后的版本，InnoDB并不会默认把各个表的数据存储到系统表空间，而是为每个表建立独立表空间，可以理解为创建多少个表，有多少个独立表空间。使用独立表空间来存储表数据的话，会在该表所属数据库对应的子目录创建一个表示该独立空间的文件，文件名和表名相同。只不过添加了.ibd扩展名而已，所以完整的文件名称是：表名.ibd。

我们可以配置使用独立表空间，还是系统表空间

on：开启独立表空间

off：开启系统表空间

⭐️其他类型表空间

随着MySQL发展，除了上述2种老牌表空间之外，现在还新提出了一些不同类型的表空间

比如通用表空间（general tablespace），undo表空间（undo tablespace），临时表空间（temporary tablespace）等。

6）MyISAM如何存储表数据

在MyISAM中的数据和索引是分开放的，所以在文件系统中也使用不同的文件来存储数据文件和索引文件，而且和InnoDB不同的是，MyISAM并没有表空间概念，表数据都存在对应数据库的子目录下。

会对应创建3个文件：

1. .MYD：数据文件
2. .MYI：索引文件
3. .sdi：这是 MyISAM 引擎在 MySQL 5.1 版本后引入的一种新类型的文件，用于存储符号数据（symbolic data）。

7）日志文件

在服务器运行中，会产生各种日志文件，比如常规的查询日志，错误日志，二进制日志，redo日志，undo日志等，日志文件记录了影响MySQL数据库的各种类型活动。

常见的日志文件：

1. 错误日志（error log）
2. 慢查询日志（slow query log）
3. 查询日志（query log）
4. 二进制文件（binlog）

---

⭐️错误日志

错误日志文件对MySQL启动，运行，关闭过程进行了记录。遇到问题时应首先查看该文件以便定位问题。该文件不仅记录了所有错误信息，也记录一些警告信息或正确信息。

用户可通过下面命令查看错误日志文件位置

show variables like 'log_error'\G

当MySQL不能正常启动时，第一个必须查找的文件是错误日志文件。

---

⭐️慢查询日志

慢查询日志，可帮助定位可能存在问题的SQL语句，从而进行SQL语句层面的优化。

开启慢查询

show variables like 'slow_query_log';set @@global.slow_query_log = on;

设置慢SQL时阈值

show variables like '%long_query_time%';set @@global.long_query_time = 5;

设置运行SQL是否使用索引并记录到慢SQL

show variables like '%log_queries_not_using_indexes%';set @@global.log_queries_not_using_indexes = on;

慢查询日志位置

show variables like 'slow_query_log_file';

---

⭐️查询日志

查看当前通用日志文件是否开启

show variables like 'general_log';set @@global.general_log = on;

通用日志文件位置

show variables like 'general_log_file';

文件日志内容

开启后，才有这个通用日志文件

---

⭐️二进制文件（binlog）

二进制文件记录了所有的DDL和DML语句（除了查询语句select），以事件的形式记录，还包含语句锁执行的消耗时间，MySQL的二进制日志是事务安全型的。

作用：

1. 恢复（recovery）：某些数据的恢复需要二进制日志。如，在一个数据库全备文件恢复后，用户可通过二进制文件进行point-in-time的恢复。
2. 复制（replication）：其原理与恢复类似，通过复制和执行二进制日志使一台远程的MySQL数据库（slave或standyby）与一台MySQL数据库（master或primary）进行实时同步。
3. 审计（audit）：用户可通过二进制日志中的信息来进行审计，破案段是否有对数据库进行注入攻击。

log-bin参数：用来控制是否开启二进制日志，默认关闭。

开启方式：在MySQL配置文件中指定如下格式

“name”为二进制日志文件的名称

如果不提供name，那么数据库会使用默认的日志文件名（文件名为主机名，后缀名为二进制日志的序列号），且文件保存在数据库所在的目录（datadir下）

log-bin=name

binlog.000x是二进制文件。

binlog.index为二进制索引文件。用来存储过往的二进制日志序号，不建议手动修改这个文件。

二进制日志文件在默认情况下并没有启动，需要手动指定参数来启动。开启这个选项会对MySQL的性能造成影响，但是性能损失十分有限。根据MySQL官方手册中的测试指明，开启二进制日志会使性能下降1%。

查看binlog开启

show variables like 'log_bin';

MySQL修改my.cnf配置

# 启用二进制日志
log_bin=mysql-bin
# 二进制日志的格式为行格式
binlog-format=ROW
# 为服务器分配了一个唯一的 ID。在 MySQL 复制环境中，每个参与复制的服务器必须有一个唯一的 server-id。
server-id=1
# 二进制日志文件自动过期删除的时间周期
expire_logs_days =30

---

⭐️其他的数据文件

除了上面所说这些用户自己存储的数据意外，数据文件下还包括为了更好运行程序的一些额外文件，这些文件不一定放在数据目录下，可在配置文件启动时另外指定存放目录

文件类型：

1. 服务器进程文件：每运行一个MySQL服务器程序，意味着启动一个进程。MySQL服务器会把自己的进程ID写到一个pid文件中。

2. socket文件：当用UNIX域套接字方式进行连接时需要的文件。（mysql.sock，mysql.sock.lock）。

3. 默认/自动生成SSL和RSA证书和密匙文件