㈠ 常见的存储引擎种类
常见的存储引擎种类
Mysql的存储引擎有好多种，其中常见的有INNODB、MyISAM、MEMORY，它们各有自已的特点及适用性，在实际中应结合应用需要来进行选择。
1. MyISAM
MyISAM是MySQL中常见的存储引擎，它曾是MySQL的默认存储引擎。它的特点是：不支持事务、也不支持外键，但访问速度比较快，占用空间小，在对事务没有太多要求仅供访问的表中适合用此种引擎。
MyISAM存储引擎的表存储成三个文件。文件的名字与表名相同。扩展名包括frm、MYD 和MYI。其中，frm为扩展名的文件存储表的结构；MYD为扩展名的文件存储数据，其是MYData的缩写；MYI为扩展名的文件存储索引，其是MYIndex的缩写。
基于MyISAM存储引擎的表支持三种不同的存储格式：静态、动态和压缩。其中前两个（静态格式和动态格式)根据正使用的列的类型（是否使用xBLOB、xTEXT、varchar）来自动选择；第三个，即已压缩格式，只能使用myisampack工具来创建。
2. INNODB
MySQL从 3.23.34a 开始包含 InnoDB 存储引擎。InnoDB具有较强的事务处理能力及较好的事务安全性并且支持外键。它给MySQL的表提供了事务提交、回滚、崩溃修复能力、还能够实现并发控制下的事务安全，在需要频繁的更新、删除操作并要求事务完整性的情况下应该选择该种存储引擎。
这种引擎不足之处是读写效率稍差，占用数据空间相对较大。
3. MEMORY
MEMORY存储引擎是MySQL中的一类特殊的存储引擎，它使用存储在内存中的内容来创建表，而且所有数据也放在内存中。其特点是访问速度快，但安全上没有保障，适用应用中涉及数据比较小、需要进行快速访问的场合。
每个基于MEMORY存储引擎的表实际对应一个磁盘文件，该文件的文件名与表名相同，类型为frm类型。该文件中只存储表的结构。而其数据文件，都是存储在内存中。这样有利于对数据的快速的处理，提高整个表的处理效率。值得注意的是，服务器需要有足够的内存来维持MEMORY存储引擎的表的使用。如果不需要使用了，可以释放这些内存，甚至可以删除不需要的表。
㈡ MySQL存储引擎之Memory
首先创建表
我们能够看到，表是不支持TEXT字段的
我们再看下文件系统
只有一个保存表结构的文件
下面我们再看下表的索引
首先，新建两个索引
我们查看当前索引类型
存在两个索引，一个为默认的，一个是指定的BTree。
接下来我们查看表的状态
Memory存储引擎表和临时表的区别
临时表分两类：系统使用临时表，create temporary table 建立的临时表。无论哪种表，只有当前session是可见的。而Memory表是所有线程都可以使用的。
系统使用临时表又分为两类：查过限制使用Myisam临时表，未超过限制使用Memory表。
使用场景
注意一点是：Memory数据易丢失，所以要求数据可再生
memory存储引擎是MySQL中的一类特殊的存储引擎。其使用存储在内存中的内容来创建表，而且所有数据也放在内存中。这些特性都与InnoDB，MyISAM存储引擎不同。
OK，这里我们讲解一些memory存储引擎的文件存储形式，索引类型，存储周期和优缺点。
每个基于memory存储引擎的表实际对应一个磁盘文件，该文件的文件名与表名相同，类型为frm类型。该文件只存储表的结构，而其数据文件，都是存储在内存中的，这样有利于对数据的快速的处理，提高整个表的处理效率。
值得注意的是：服务器需要有足够的内存来维持memory存储引擎的表的使用。如果不需要了，可以释放这些内存，甚至可以删除不需要的表。
Memory存储引擎默认使用哈希(HASH)索引，其速度比使用B型树(BTREE)索引快。如果我们需要使用B型树索引，可以在创建索引时选择使用。
这里来整理一个小的技巧：
Memory存储引擎通常很少用到，至少我是没有用到过。因为Memory表的所有数据都是存储在内存上的，如果内存出现异常会影响到数据的完整性。
如果重启机器或者关机，表中的所有数据都将消失，因此，基于Memory存储引擎的表的生命周期都比较短，一般都是一次性的。
Memory表的大小是受到限制的，表的大小主要取决于2个参数，分别是max_rows和max_heap_table_size。其中，max_rows可以在创建表时指定，max_heap_table_size的大小默认为16MB，可以按需要进行扩大。
因此，其基于内存中的特性，这类表的处理速度会非常快，但是，其数据易丢失，生命周期短。基于其这个缺陷，选择Memory存储引擎时需要特别小心。
㈢ 如何为mysql数据库添加新的存储引擎
mysql 5.5以前默认的引擎是myisam，5.5以后是innodb，引擎可以在创建表的时候指定，如下：
Ceate table test
(id int,name varchar(10))
engine innodb;
修改：
alter table test type=innodb;
如果想设置缺省引擎可以在配置文件的mysqld添加一行：
default-storage-engine=INNODB;
㈣ 什么是MySQL存储引擎
MySQL 可能是最着名的 关系数据库管理系统 (RDBMS),作为一款免费开源软件开发，最初由 MYSQL AB 公司提供支持，但现在归 Oracle 所有。
在 MySQL 中，用于表的“存储引擎”决定了数据的处理方式。有几种可用的存储引擎，但最常用的是 InnoDB 和 MyISAM 。
在本文中，我们将了解它们的显着特征以及它们之间的主要区别。
在本教程中，您将学习：
在我们讨论两个主要 MySQL 存储引擎之间的特性和区别之前，先来了解一下什么是存储引擎？
存储引擎，也称为“ 表处理程序 ”，基本上是解释和管理与数据库表的 SQL 查询相关的操作的数据库部分。
在最新版本的 MySQL 中，可以使用“ 可插拔 ”架构来组织和管理存储引擎，存在多种存储引擎，但最常用的两个是 InnoDB 和 MyISAM 。
要获得我们正在使用的数据库中可用存储引擎的列表，我们所要做的就是发出一个简单的 SQL 查询，因此我们需要做的第一件事就是打开一个 MySQL 交互式提示并使用数据库用户登录及其密码：
如果登录成功，提示将变为mysql>，在这里，我们可以运行我们的 SQL 查询来可视化可用的存储引擎：
执行查询后，我们应该获得类似于以下内容的结果：
在上表中，作为查询结果生成，我们可以通过查看Support每行列中的值轻松了解支持哪些存储引擎，“YES”值表示存储引擎可用，否则“NO”。相反，同一列中的“DEFAULT”值表示相应的引擎（在本例中为 InnoDB）是服务器使用的默认引擎。
“ Transactions ”和“ Savepoints ”列中存在的值分别表示存储引擎是否支持事务和回滚。正如我们通过查看表可以看到的，只有 InnoDB 引擎可以。
关于存储引擎的信息存在于“ INFORMATION_SCHEMA ”数据库的“ ENGINES ”表中，因此我们也可以发出标准的“SELECT”查询来获取我们需要的数据：
我们将获得与上面看到的相同的结果。
让我们看看两个最常用的存储引擎 InnoDB 和 MyISAM 之间的主要特性和区别是什么。
正如我们已经说过的， InnoDB 是自 MySQL 以来的默认存储引擎5.5。
此存储引擎的一些主要功能如下：
对事务的支持提供了一种安全的方式来执行多个查询以保持数据一致。
当多个修改数据的操作被执行并且我们想要确保它们只有在所有操作都成功并且没有错误发生时才有效时，我们想要使用事务。
典型的处理方式是启动事务并执行查询：如果出现错误，则执行回滚，否则提交更改。
当使用 InnoDB 数据锁定发生在行级别时，因此在事务期间锁定的数据量是有限的。
InnoDB 有两种类型的锁：
一个共享锁允许谁拥有它读取该行的交易，而一个排它锁允许交易执行其修改行的操作，所以要更新或删除数据。
当一个事务在某行上获得共享锁，而另一个事务需要相同的锁类型时，立即授予；但是，如果第二个事务在同一行上请求排他锁，它将不得不等待。
如果第一个事务持有该行的排他锁，则第二个事务将不得不等待该锁被释放以获得共享锁或排他锁。
外键是一个非常重要的特性，因为它们可用于基于表之间的逻辑关系来强制执行数据完整性。想象一下，我们的数据库中有三个表（假设它被称为“testdb”）：一个user包含现有用户的job表，一个注册所有可用作业的user_job表，以及一个用于表示用户和用户之间存在的多对多关系的表。作业（一个用户可以有多个作业，多个作业可以与同一个用户关联）。
该user_job表就是所谓的连接表或关联表，因为它的唯一目的是表示用户-工作关联。该表有两列，一个叫user_id和其他job id。表中会存在两个外键约束，强制执行以下规则：user_id列中的值只能引用表id列中的值，列中的user值job_id必须引用表id列中的现有值job.
这将强制执行完整性，因为仅允许现有用户和作业的 ID 存在于关联表中。删除涉及表中一个或多个关联的用户或作业user_job也是不允许的，除非为相应的外键设置了CASCADE DELETE规则。在这种情况下，当删除用户或作业时，它们所涉及的关系也将被删除。
MyISAM 曾经是默认的 MySQL 存储引擎，但已被 InnoDB 取代。使用此引擎时，数据锁定发生在表级别，因此执行操作时锁定的数据更多。
与 InnoDB 不同，MyISAM 不支持事务回滚和提交，因此必须手动执行回滚。MyISAM 和 InnoDB 之间的另一个很大区别是前者不支持外键。MyISAM 更简单，并且在对有限数据集进行读取密集型操作时可能具有优势（有争议）。
在表上使用 MyISAM 时，会设置一个标志，指示该表是否需要修复，例如在突然关闭之后。稍后可以使用适当的工具执行表修复。
如何知道特定表使用了什么存储引擎？我们所要做的就是发出一个简单的查询。
例如，要知道user我们在前面的例子中提到的表使用了什么存储引擎，我们将运行：
注意上面的查询我们使用了G，为了让查询结果垂直显示，优化空间。执行查询后，我们将获得以下结果：
在这种情况下，通过查看“Engine”列中存储的值，我们可以清楚地看到该表使用的是“InnoDB”引擎。获取相同信息的另一种方法是INFORMATION_SCHEMA.TABLES直接查询表：
上面的查询将只返回表使用的引擎：
如果我们稍微更改查询，我们可以获得数据库中所有表名的列表以及它们使用的引擎：
如果我们要为一个表设置一个特定的存储引擎，我们可以在创建时指定它。例如，假设我们正在创建job表，并且出于某种原因我们想要使用 MyISAM 存储引擎。我们将发出以下 SQL 查询：
相反，如果我们想要更改用于已存在表的存储引擎，我们只需要使用ALTERSQL 语句。假设我们要将上一个示例中创建的“job”表所使用的存储引擎更改为 InnoDB；我们会运行：
在本教程中，我们学习了什么是数据库存储引擎，并且我们看到了两个最常用的 MySQL 引擎的主要特性： InnoDB 和 MyISAM 。
我们看到了如何检查哪些引擎可用、哪些引擎用于表以及如何使用 SQL 查询设置和修改表引擎。
㈤ MySQL存储引擎
InnoDB的数据文件本身就是主索引文件。而MyISAM的主索引和数据是分开的。辅助索引data域存储相应记录主键的值而不是地址。
innoDB是聚簇索引，数据挂在逐渐索引之下。
是 MySQL 默认的事务型存储引擎， 只有在需要它不支持的特性时，才考虑使用其它存储引擎 。
实现了四个标准的隔离级别，默认级别是可重复读(REPEATABLE READ)。在可重复读隔离级别下，通过多版本并发控制(MVCC)+ 间隙锁(Next-Key Locking)防止幻影读。
主索引是聚簇索引，在索引中保存了数据，从而避免直接读取磁盘，因此对查询性能有很大的提升。
内部做了很多优化，包括从磁盘读取数据时采用的可预测性读、能够加快读操作并且自动创建的自适应哈希索引、能够加速插入操作的插入缓冲区等。
支持真正的在线热备份。其它存储引擎不支持在线热备份，要获取一致性视图需要停止对所有表的写入，而在读写混合场景中，停止写入可能也意味着停止读取。
以B+树作为索引结构，叶节点的数据域存放数据记录的地址。主索引和辅助索引在结构上没有区别，只是主索引要求key唯一，而辅助索引的key可以重复。
MyISAM中索引检索的算法为首先按照B+Tree搜索算法搜索索引，如果指定的Key存在，则取出其data域的值，然后以data域的值为地址，读取相应数据记录。
设计简单，数据以紧密格式存储。对于只读数据，或者表比较小、可以容忍修复的操作，则依然可以使用它。
提供了大量的特性，包括压缩表、空间数据索引等。
不支持事务 。
不支持行级锁，只能对整张表加锁，读取时会对需要读到的所有表加共享锁，写入时则对表加排它锁。但在表有读取操作的同时，也可以往表中插入新的记录，这被称为并发插入(CONCURRENT INSERT)。
可以手工或者自动执行检查和修复操作，但是和事务恢复以及崩溃恢复不同，可能导致一些数据丢失，而且修复操作是非常慢的。
如果指定了 DELAY_KEY_WRITE 选项，在每次修改执行完成时，不会立即将修改的索引数据写入磁盘，而是会写到内存中的键缓冲区，只有在清理键缓冲区或者关闭表的时候才会将对应的索引块写入磁盘。这种方式可以极大地提升写入性能，但是在数据库或者主机崩溃时会造成索引损坏，需要执行修复操作。
㈥ 03-Docker存储引擎
目前docker的默认存储引擎为overlay2，不同的存储引擎需要相应的文件系统支持，如需要磁盘分区的时候传递d-type稳健分层功能，即需要传递内核参数并开启格式化磁盘的时候指定的功能
Docker 存储引擎的核心思想是“层”的概念，理解了这个层，就基本可以理解它的设计思路。当我们拉取一个 Docker 镜像的时候，可以看到如下:
一个镜像被分成许多的“层”，每“层”包含了若干的文件，而一层层堆叠起来就组成了我们的一个完整的镜像。我们镜像中的文件就是所有“层”文件的并集。 我们构建 Docker 镜像一般采用 Dockerfile 的方式，而 Dockerfile 的每行命令，其实就会生成一个“层”，即使什么文件都没有添加。
文件的创建是在读写层增加文件，那修改和删除呢？
这就要提一下 Docker 设计的 -on-write (CoW) 策略。
当我们试图读取一个文件时，Docker 会从上到下一层层去找这个文件，找到的第一个就是我们的文件。所以下面层相同的文件就被“覆盖”了。而修改就是当我们找到这个文件时，将它“复制”到读写层并修改，这样读写层的文件就是我们修改后的文件，并且“覆盖”了镜像中的文件了。而删除就是创建了一个特殊的 whiteout 文件，这个 whiteout 文件覆盖的文件即表示删除了。
这样的设计有什么好处吗？
第一个好处是减少了存储空间，由于镜像被分成了多个层，而各个层是静态只读的，是可以共享的。当你从一个镜像构建另一个镜像时，只需要添加新的层，原有的层不会被复制。
我们可以用 docker history 命令查看我们创建的镜像，相同的层将共享且只保存一份。
我们可以在系统的 /var/lib/docker/<存储驱动>/ 下看到我们所有的层。
第二个好处是启动容器就变得非常轻量和快速。因为我们的容器只是添加了一个“空”的读写层，其他的都是复用的只读层，需要用时才会去搜索。
Docker 的存储引擎针对不同的文件系统，是由不同的存储驱动。
Docker 主要有一下几类存储驱动：
有条件的情况下，我们还是建议选择 overlay2 的存储驱动。
Linux 系统正常运行, 通常需要两个文件系统:
OverlayFS 是从 aufs 之上改进和简化而来的，比 aufs 和 devicemapper 有更好的性能，大部分情况下也比 btrfs 好。
OverlayFS 结构分为三个层: LowerDir 、 Upperdir 、 MergedDir
LowerDir、Upperdir、MergedDir 关系图:
特性：
获取镜像存储路径
Lower层
LowerDir 层的存储是不允许创建文件, 此时的LowerDir实际上是其他的镜像的UpperDir层，也就是说在构建镜像的时候, 如果发现构建的内容相同, 那么不会重复的构建目录，而是使用其他镜像的Upper 层来作为本镜像的Lower
Merged层
属于对外展示层，只能在运行中的容器查看，镜像是查看不了的
1）查看init层地址指向
容器在启动的过程中, Lower 会自动挂载init的一些文件
2) init层主要内容是什么?
init层是以一个uuid+-init结尾表示，放在只读层(Lowerdir)和读写层(Upperdir)之间,
作用只是存放/etc/hosts、/etc/resolv.conf 等文件。
3) 为什么需要init层?
(1) 容器在启动以后, 默认情况下lower层是不能够修改内容的, 但是用户有需求需要修改主机名与域名地址, 那么就需要添加init层中的文件(hostname, resolv.conf), 用于解决此类问题.
(2) 修改的内容只对当前的容器生效, 而在docker commit提交为镜像时候,并不会将init层提交。
(3) init 文件存放的目录为/var/lib/docker/overlay2/<init_id>/diff
4) 查看init层文件
hostname与resolv.conf 全部为空文件, 在系统启动以后由系统写入。
配置 Docker 存储驱动非常简单，只需要修改配置文件即可。
方法1
方法2