DBA技术栈（二）：MySQL 存储引擎_bdb存储引擎，2024年最新看完阿里P9大牛的“Linux运维成长笔记”我悟了

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Linux运维全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上运维知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024b （备注运维）

正文

2.1 MySQL存储引擎概述

上个业余的图：

MyISAM 存储引擎是 MySQL 默认的存储引擎，也是目前 MySQL 使用最为广泛的存储引擎之一。他的前身就是我们在 MySQL 发展历程中所提到的 ISAM，是 ISAM 的升级版本。在 MySQL最开始发行的时候是 ISAM 存储引擎，而且实际上在最初的时候，MySQL 甚至是没有存储引擎这个概念的。MySQL在架构上面也没有像现在这样的sql layer和storage engine layer这两个结构清晰的层次结构，当时不管是代码本身还是系统架构，对于开发者来说都很痛苦的一件事情。
5.1 之前的 版本中，虽然存储引擎层和 sql层的耦合已经非常少了，基本上完全是通过接口来实现交互，但是这两层之间仍然是没办法分离的，即使在安装的时候也是一样。

MySQL5.1 开始，MySQL AB 对其结构体系做了较大的改造，并引入了一个新的概念：插件式存储引擎体系结构。MySQL AB 在架构改造的时候，让存储引擎层和 sql 层各自更为独立，耦合更小，甚至可以做到在线加载信的存储引擎，也就是完全可以将一个新的存储引擎加载到一个正在 运行的 MySQL 中，而不影响 MySQL 的正常运行。插件式存储引擎的架构，为存储引擎的加载和移出更为灵活方便，也使自行开发存储引擎更为方便简单。在 这
一点上面，目前还没有哪个数据库管理系统能够做到。MySQL 的插件式存储引擎主要包括 MyISAM，Innodb，NDB Cluster，Maria，Falcon，Memory，Archive，Merge，Federated 等，**其中最著名而且使用最为广泛的 MyISAM 和 Innodb两种存储引擎。**MyISAM 是 MySQL 最早的 ISAM 存储引擎的升级版本，也是 MySQL 默认的存储
引擎。而 Innodb 实 际上并不是 MySQ 公司的，而是第三方软件公司 Innobase（在 2005 年被 Oracle 公司所收购）所开发，其最大的特点是提供了事务控制等特性， 所以使用者也非常广泛。

2.2 MySQL存储引擎介绍

MyISAM 存储引擎简介

MyISAM 存储引擎的表在数据库中，每一个表都被存放为三个以表名命名的物理文件。首先肯定会有任何存储引擎都不可缺少的存放表结构定义信息的.frm 文件，另外还有.MYD和.MYI 文件，分别存放了表的数据（.MYD）和索引数据（.MYI）。每个表都有且仅有这样三个文件做为 MyISAM 存储类型的表的存储，也就是说不管这个表有多少个索引，都是存放在同一个.MYI 文件中。

MyISAM 支持以下三种类型的索引：

1、B-Tree 索引

B-Tree 索引，顾名思义，就是所有的索引节点都按照 balance tree 的数据结构来存储，所有的索引数据节点都在叶节点。

2、R-Tree 索引

R-Tree 索引的存储方式和 b-tree 索引有一些区别，主要设计用于为存储空间和多维数据的字段做索引，所以目前的 MySQL 版本来说，也仅支持 geometry 类型的字段作索引。

3、Full-text 索引

Full-text 索引就是我们长说的全文索引，他的存储结构也是 b-tree。主要是为了解决在我们需要用 like 查询的低效问题。
MyISAM 上面三种索引类型中，最经常使用的就是 B-Tree 索引了，偶尔会使用到 Fulltext，但是 R-Tree 索引一般系统中都是很少用到的。另外 MyISAM 的 B-Tree 索引有一个较大的限制，那就是参与一个索引的所有字段的长度之和不能超过 1000 字节。

虽然每一个 MyISAM 的表都是存放在一个相同后缀名的.MYD 文件中，但是每个文件的存放格式实际上可能并不是完全一样的，因为 MyISAM 的数据存放格式是分为静态（FIXED）固定长度、动态（DYNAMIC）可变长度以及压缩（COMPRESSED）这三种格式。当然三种格式中是否压缩是完全可以任由我们自己选择的，可以在创建表的时候通过 ROW_FORMAT 来指定{COMPRESSED | DEFAULT}，也可以通过 myisampack 工具来进行压缩，默认是不压缩的。而在非压缩的情况下，是静态还是动态，就和我们表中个字段的定义相关了。只要表中有可变长度类型的字段存在，那么该表就肯定是 DYNAMIC 格式的，如果没有任何可变长度的字段，则为 FIXED 格式，当然，你也可以通过 alter table 命令，强行将一个带有 VARCHAR 类型字段的 DYNAMIC 的表转换为 FIXED，但是所带来的结果是原 VARCHAR 字段类型会被自动转换成CHAR 类型。相反如果将 FIXED 转换为 DYNAMIC，也会将 CHAR 类型字段转换为 VARCHAR 类型，
所以大家手工强行转换的操作一定要谨慎。

MyISAM 存储引擎的表是否足够可靠呢？在 MySQL 用户参考手册中列出在遇到如下情况的时候可能会出现表文件损坏：

1、当 mysqld 正在做写操作的时候被 kill 掉或者其他情况造成异常终止；

2、主机 Crash；

3、磁盘硬件故障；

4、MyISAM 存储引擎中的 bug？

MyISAM 存储引擎的某个表文件出错之后，仅影响到该表，而不会影响到其他表，更不会影响到其他的数据库。如果我们的出据苦正在运行过程中发现某个 MyISAM 表出现问题了，则可以在线通过 check table 命令来尝试校验他，并可以通过 repair table 命令来尝试修复。在数据库关闭状态下，我们也可以通过 myisamchk 工具来对数据库中某个（或某些）表进行检测或者修复。不过强烈建议不到万不得已不要轻易对表进行修复操作，修复之前尽量做好可能的备份工作，以免带来不必要的后果。另外 MyISAM 存储引擎的表理论上是可以被多个数据库实例同时使用同时操作的，但是不论是我们都不建议这样做，而且 MySQL 官方的用户手册中也有提到，建议尽量不要在多个mysqld 之间共享 MyISAM 存储文件。

Innodb 存储引擎简介

在 MySQL 中使用最为广泛的除了 MyISAM 之外，就非 Innodb 莫属了。Innodb 做为第三方公司所开发的存储引擎，和 MySQL 遵守相同的开源 License 协议。Innodb 之所以能如此受宠，主要是在于其功能方面的较多特点：
1、支持事务安装
Innodb在功能方面最重要的一点就是对事务安全的支持，这无疑是让Innodb成为MySQL最为流行的存储引擎之一的一个非常重要原因。而且实现了 SQL92 标准所定义的所有四个级别（READ UNCOMMITTED，READ COMMITTED，REPEATABLE READ, SERIALIZABLE）。对事务安全的支持，无疑让很多之前因为特殊业务要求而不得不放弃使用 MySQL 的用户转向支持MySQL，以及之前对数据库选型持观望态度的用户，也大大增加了对 MySQL 好感。
2、数据多版本读取
Innodb 在事务支持的同时，为了保证数据的一致性已经并发时候的性能，通过对 undo
信息，实现了数据的多版本读取。
3、锁定机制的改进
Innodb 改变了 MyISAM 的锁机制，实现了行锁。虽然 Innodb 的行锁机制的实现是通过
索引来完成的，但毕竟在数据库中 99%的 SQL 语句都是要使用索引来做检索数据的。所以，
行锁定机制也无疑为 Innodb 在承受高并发压力的环境下增强了不小的竞争力。
4、实现外键
Innodb 实现了外键引用这一数据库的重要特性，使在数据库端控制部分数据的完整性成为可能。虽然很多数据库系统调优专家都建议不要这样做，但是对于不少用户来说在数据库端加如外键控制可能仍然是成本最低的选择。
除了以上几个功能上面的亮点之外，Innodb 还有很多其他一些功能特色常常带给使用者不小的惊喜，同时也为 MySQL 带来了更多的客户。
在物理存储方卖弄，Innodb 存储引擎也和 MyISAM 不太一样，虽然也有.frm 文件来存放表结构定义相关的元数据，但是表数据和索引数据是存放在一起的。至于是每个表单独存放还是所有表存放在一起，完全由用户来决定（通过特定配置），同时还支持符号链接。

Innodb 的物理结构分为两大部分：

1、数据文件（表数据和索引数据）

存放数据表中的数据和所有的索引数据，包括主键和其他普通索引。在 Innodb 中，存在了表空间（tablespace）这样一个概念，但是他和 Oracle 的表空间又有较大的不同。首先，Innodb 的表空间分为两种形式。一种是共享表空间，也就是所有表和索引数据被存放在同一个表空间（一个或多个数据文件）中，通过 innodb_data_file_path 来指定，增加数据文件需要停机重启。 另外一种是独享表空间，也就是每个表的数据和索引被存放在一个单独的.ibd 文件中。
虽然我们可以自行设定使用共享表空间还是独享表空间来存放我们的表，但是共享表空间都是必须存在的，因为 Innodb 的 undo 信息和其他一些元数据信息都是存放在共享表空间里面的。共享表空间的数据文件是可以设置为固定大小和可自动扩展大小两种形式的，自动扩展形式的文件可以设置文件的最大大小和每次扩展量。在创建自动扩展的数据文件的时候，建议大家最好加上最大尺寸的属性，一个原因是文件系统本身是有一定大小限制的（但是 Innodb 并不知道），还有一个原因就是自身维护的方便。另外，Innodb 不仅可以使用文
件系统，还可以使用原始块设备，也就是我们常说的裸设备。当我们的文件表空间快要用完的时候，我们必须要为其增加数据文件，当然，只有共享表 空 间 有 此 操 作 。 共 享 表 空 间 增 加 数 据 文 件 的 操 作 比 较 简 单 ， 只 需 要 在innodb_data_file_path 参数后面按照标准格式设置好文件路径和相关属性即可，不过这里有一点需要注意的，就是 Innodb 在创建新数据文件的时候是不会创建目录的，如果指定目录不存在，则会报错并无法启动。另外一个较为令人头疼的就是 Innodb 在给共享表空间增加数据文件之后，必须要重启数据库系统才能生效，如果是使用裸设备，还需要有两次重启 。这也是我一直不太喜欢使用共享表空间而选用独享表空间的原因之一。

2、日志文件

Innodb 的日志文件和 Oracle 的 redo 日志比较类似，同样可以设置多个日志组（最少 2个），同样采用轮循策略来顺序的写入，甚至在老版本中还有和 Oracle 一样的日志归档特性 。如果你的数据库中有创建了 Innodb 的表，那么千万别全部删除 innodb 的日志文件，因为很可能就会让你的数据库 crash，无法启动，或者是丢失数据。由于 Innodb 是事务安全的存储引擎，所以系统 Crash 对他来说并不能造成非常严重的损失，由于有 redo 日志的存在，有 checkpoint 机制的保护，Innodb 完全可以通过 redo 日志将数据库 Crash 时刻已经完成但还没有来得及将数据写入磁盘的事务恢复，也能够将所有部分完成并已经写入磁盘的未完成事务回滚并将数据还原。

Innodb 不仅在功能特性方面和 MyISAM 存储引擎有较大区别，在配置上面也是单独处理的。在 MySQL 启动参数文件设置中，Innodb 的所有参数基本上都带有前缀“innodb_”，不论是 innodb 数据和日志相关，还是其他一些性能，事务等等相关的参数都是一样。和所有Innodb 相关的系统变量一样，所有的 Innodb 相关的系统状态值也同样全部以“Innodb_”前缀。当然，我们也完全可以仅仅通过一个参数（skip-innodb）来屏蔽 MySQL 中的 Innodb存储引擎，这样即使我们在安装编译的时候将 Innodb 存储引擎安装进去了，使用者也无法创建 Innodb 的表。

NDB Cluster 存储引擎简介

NDB 存储引擎也叫 NDB Cluster 存储引擎，主要用于 MySQL Cluster 分布式集群环境，Cluster 是 MySQL 从 5.0 版本才开始提供的新功能。这部分我们可能并不仅仅只是介绍 NDB存储引擎，因为离开了 MySQL CLuster 整个环境，NDB 存储引擎也将失去太多意义。 简单的说，Mysql Cluster 实际上就是在无共享存储设备的情况下实现的一种内存数据库 Cluster 环境，其主要是通过 NDB Cluster（简称 NDB）存储引擎来实现的。

一般来说，一个 Mysql Cluster 的环境主要由以下三部分组成：
a) 负责管理各个节点的 Manage 节点主机：
管理节点负责整个 Cluster 集群中各个节点的管理工作，包括集群的配置，启动关闭各节点，以及实施数据的备份恢复等。管理节点会获取整个 Cluster 环境中各节点的状态和错误信息，并且将各 Cluster 集群中各个节点的信息反馈给整个集群中其他的所有节点。由于管理节点上保存在整个 Cluster 环境的配置，同时担任了集群中各节点的基本沟通工作，所以他必须是最先被启动的节点。

b) SQL 层的 SQL 服务器节点（后面简称为 SQL 节点），也就是我们常说的 Mysql Server：
主要负责实现一个数据库在存储层之上的所有事情，比如连接管理，query 优化和响应，cache 管理等等，只有存储层的工作交给了 NDB 数据节点去处理了。也就是说，在纯粹的 Mysql Cluster 环境中的 SQL 节点，可以被认为是一个不需要提供任何存储引擎的 Mysql服务器，因为他的存储引擎有 Cluster 环境中的 NDB 节点来担任。所以，SQL 层各 Mysql 服务器的启动与普通的 Mysql 启动有一定的区别，必须要添加 ndbcluster 项，可以添加在my.cnf 配置文件中，也可以通过启动命令行来指定。

c) Storage 层的 NDB 数据节点，也就是上面说的 NDB Cluster：
NDB 是一个内存式存储引擎也就是说，他会将所有的数据和索引数据都 load 到内存中 ，但也会将数据持久化到存储设备上。不过，最新版本，已经支持用户自己选择数据可以不全部 Load 到内存中了，这对于有些数据量太大或者基于成本考虑而没有足够内存空间来存放所有数据的用户来说的确是一个大好消息。

NDB 节点主要是实现底层数据存储的功能，保存 Cluster 的数据。每一个 NDB 节点保存完整数据的一部分（或者一份完整的数据，视节点数目和配置而定），在 MySQL CLuster 里面叫做一个 fragment。而每一个 fragment，正常情况来讲都会在其他的主机上面有一份（或者多分）完全相同的镜像存在。这些都是通过配置来完成的，所以只要配置得当，MysqlCluster 在存储层不会出现单点的问题。

最后的话

最近很多小伙伴找我要Linux学习资料，于是我翻箱倒柜，整理了一些优质资源，涵盖视频、电子书、PPT等共享给大家！

资料预览

给大家整理的视频资料：

给大家整理的电子书资料：

如果本文对你有帮助，欢迎点赞、收藏、转发给朋友，让我有持续创作的动力！

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注运维）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
的资料的朋友，可以添加V获取：vip1024b （备注运维）**
[外链图片转存中…(img-8z291QVl-1713315523346)]

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！