首先创建表
我们能够看到，表是不支持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存储引擎时需要特别小心。
‘贰’ Docker基础
Docker 是一个开源的应用容器引擎，基于Go 语言 并遵从 Apache2.0 协议开源。
Docker 可以让开发者打包他们的应用以及依赖包到一个轻量级、可移植的容器中，然后发布到任何流行的 Linux 机器上，也可以实现虚拟化。
容器是完全使用沙箱机制，相互之间不会有任何接口（类似 iPhone 的 app）,更重要的是容器性能开销极低。
Docker最早是在Ubuntu 12.04上开发实现的；
Red Hat则从RHEL6.5开始对Docker进行支持。
而后Windows和Mac上也相应有了Docker版本支持。
在Docker容器技术出现之前，Linux上是已经有一个docker的工具的，但此docker非彼Docker。
这个docker是一个窗口停靠栏程序，就像苹果的Mac系统中的dock那个程序一样的一个工具。
为了区分开来，我们以Docker和docker来进行区分。
Docker：指容器技术。
docker：指窗口停靠栏程序。
Docker技术出来后，因为Linux系统上已经有了docker这个工具，所以Docker软件名也不能跟人家重名啊，要不然没办法安装。
由于那个时候Docker的官网是docker.io，所以就在软件名称上加了io的后缀，在Ubuntu中就是docker.io，在CentOS中就是docker-io。
但是虽然软件名跟docker程序不一样了，但软件安装后的操作命令还是一样的，都是docker的这个命令，所以要安装Docker软件，要先看看有没有安装了那个停靠栏程序docker，有的话要先卸载才行，要不然执行的命令是不对的。
这个时期要安装Docker，就要用docker加io后缀的方式来安装。
Docker容器使用docker.io和docker-io为软件名，主要是前期的一段时间。
后来随着Docker的发展，软件包名改成了docker-engine,不同系统中名称达到了统一。
再后来，随着Docker技术的火爆，在征得docker停靠栏程序作者同意下，原先的停靠栏程序docker名称改掉了，改成了wmdocker，Docker容器技术的软件包名才正式成了docker这个名称，Docker软件包的名称又得到了一次完全的统一。
到Docker1.13.1版本之前，Docker软件包的名称有两次变化，从docker-io(docker.io)到docker-engine,再到docker。
Docker发展到1.13.1版本号后，Docker公司把Docker分成了社区版(免费)Docker CE和商业版(付费)Docker EE两种形式，并且版本号命名方式也改了，以前是那种常用的版本号命令方式，比如0.1、0.2、1.0之类的，现在分社区和商业版后，版本号是“年.月”的形式命名的，比如2019年10月发布的，版本号就是19.10。
所以在Docker1.13.1之后，直接是Docker-ce 17.03.0版本了，也就是2017年03月发布的。
现在要安装最新版的Docker软件包，就是使用docker-ce这个名称了，如果是商业版的就是docker-ee了。
目前docker的默认存储引擎为overlay2，不同的存储引擎需要相应的文件系统支持，如需要磁盘分区的时候传递d-type稳健分层功能，即需要传递内核参数并开启格式化磁盘的时候指定的功能。
存储引擎的选择文档
AUFS
AUFSAnotherUnionFileSystem是一种UnionFS。V2版本后更名为 advanced multi‐layered unification fileystem，即高级多层统一文件系统。所谓UnionFS就是把不同物理位置的目录合并mount到同一个目录中。简单来说就是支持将不同目录挂载到同一个虚拟文件系统下的文件系统。这种系统可以一层一层的叠加修改文件。无论底下有多少层都是只读，只有最上层的文件系统是可读写。当需要修改一个文件时，AUFS创建该文件的一个副本。使用CoWCopy-on-Write将文件从只读层复制到可写层进行修改，结果也保留在可写层、在Docker中。底下的制度层就是image，可写层就是Container。
Overlay
一种Union FS文件系统，Linux内核3.18后支持
Overlay2
overlay的升级版，到目前为止，所有Linux发行版推荐使用的存储类型
devicemapper
是CentOS和RHEL的推荐存储驱动程序，但是依赖于direct-lvm，存在空间受限的问题，虽然可以通过后期配置解决；因为之前的内核版本不支持overlay2（集中在Centos/RHEL7.2之前版本）；但当前较新版本Centos和RHEL现已经支持overlay2。
https://www.cnblogs.com/youruncloud/p/5736718.html
zfs/btrfs(Oracle-2007)
目前没有广泛应用；这些文件系统允许使用高级选项，例如创建“快照”，但需要更多的维护和设置。并且每一个都依赖于正确配置的后备文件系统。
vfs
用于测试环境，适用于无法适用Cow文件系统的情况。此存储驱动程序的性能很差，通常不建议在生产中使用。
1）overlay存储驱动程序已在Docker Engine-Enterprise 18.09中弃用，并将在以后的版本中删除。建议将overlay存储驱动程序的用户迁移到overlay2。
2）devicemapper存储驱动程序已在Docker Engine 18.09中弃用，并将在以后的版本中删除。建议将devicemapper存储驱动程序的用户迁移到overlay2。
建议使用overlay2存储驱动程序。首次安装Docker时，默认情况下使用overlay2。早期版本，默认情况下会使用aufs。如果要在新版本中使用aufs，则需要对其配置，并且可能需要安装其他软件包，例如linux-image-extra。
对于Docker，支持文件系统是所在的文件系统 /var/lib/docker/。一些存储驱动程序仅适用于特定的后备文件系统。
配置 Docker 存储驱动非常简单，只需要修改配置文件即可。
‘叁’ mysql最大容量有多大
在老版本的MySQL 3.22中，MySQL的单表限大小为4GB，当时的MySQL的存储引擎还是ISAM存储引擎。但是，当出现MyISAM存储引擎之后，也就是从MySQL 3.23开始，MySQL单表最大限制就已经扩大到了64PB了（官方文档显示）。也就是说，从目前的技术环境来看，MySQL数据库的MyISAM存储 引擎单表大小限制已经不是有MySQL数据库本身来决定，而是由所在主机的OS上面的文件系统来决定了。
而MySQL另外一个最流行的存储引擎之一Innodb存储数据的策略是分为两种的，一种是共享表空间存储方式，还有一种是独享表空间存储方式。
当使用共享表空间存储方式的时候，Innodb的所有数据保存在一个单独的表空间里面，而这个表空间可以由很多个文件组成，一个表可以跨多个文件存在，所 以其大小限制不再是文件大小的限制，而是其自身的限制。从Innodb的官方文档中可以看到，其表空间的最大限制为64TB，也就是说，Innodb的单 表限制基本上也在64TB左右了，当然这个大小是包括这个表的所有索引等其他相关数据。
而当使用独享表空间来存放Innodb的表的时候，每个表的数据以一个单独的文件来存放，这个时候的单表限制，又变成文件系统的大小限制了。
‘肆’ mysql5.7 为什么没有my.ini
mysql5.7 为什么没有my.ini
在老版本的MySQL 3.22中，MySQL的单表限大小为4GB，当时的MySQL的存储引擎还是ISAM存储引擎。但是，当出现MyISAM存储引擎之后，也就是从MySQL 3.23开始，MySQL单表最大限制就已经扩大到了64PB了（官方文档显示）。也就是说，从目前的技术环境来看，MySQL数据库的MyISAM存储 引擎单表大小限制已经不是有MySQL数据库本身来决定，而是由所在主机的OS上面的文件系统来决定了。
而MySQL另外一个最流行的存储引擎之一Innodb存储数据的策略是分为两种的，一种是共享表空间存储方式，还有一种是独享表空间存储方式。
当使用共享表空间存储方式的时候，Innodb的所有数据保存在一个单独的表空间里面，而这个表空间可以由很多个文件组成，一个表可以跨多个文件存在，所 以其大小限制不再是文件大小的限制，而是其自身的限制。从Innodb的官方文档中可以看到，其表空间的最大限制为64TB，也就是说，Innodb的单 表限制基本上也在64TB左右了，当然这个大小是包括这个表的所有索引等其他相关数据。
而当使用独享表空间来存放Innodb的表的时候，每个表的数据以一个单独的文件来存放，这个时候的单表限制，又变成文件系统的大小限制了。
‘伍’ mysql哪个存储引擎有表空间
一、系统表空间
在 MySQL 数据目录下有一个名为 ibdata1 的文件，可以保存一张或者多张表。
923275 12M -rw-r----- 1 mysql mysql 12M 3月 18 10:42 ibdata1
这个文件就是 MySQL 的系统表空间文件，默认为 1 个，可以有多个，只需要在配置文件 my.cnf 里面这样定义即可。
innodb_data_file_path=ibdata1:200M;ibdata2:200M:autoextend:max:800M系统表空间不仅可以是文件系统组成的文件，也可以是非文件系统组成的磁盘块，比如裸设备，定义也很简单innodb_data_file_path=/dev/nvme0n1p1:3Gnewraw;/dev/nvme0n1p2:2Gnewraw
系统表空间里都有些啥内容？
具体内容包括：double writer buffer、 change buffer、数据字典（MySQL 8.0 之前）、表数据、表索引。
那 MySQL 为什么现在主流版本默认都不是系统表空间？
究其原因，系统表空间有三个最大的缺点：原因 1：无法做到自动收缩磁盘空间，造成很大的空间浪费。即使它包含的表都被删掉，这部分空间也不会自动释放。
二、单表空间
单表空间不同于系统表空间，每个表空间和表是一一对应的关系，每张表都有自己的表空间。具体在磁盘上表现为后缀为 .ibd 的文件。比如表 t1，对应的表空间文件为 t1.ibd917107 96K -rw-r----- 1 mysql mysql 96K 3月 18 16:13 t1.ibd
单表空间如何应用到具体的表呢？
有两种方式：方式 1：在配置文件中开启。在配置文件中开启单表空间设置参数 innodb_filer_per_table，这样默认对当前库下所有表开启单表空间。innodb_file_per_table=1另外也可以直接建表时指定单表空间mysql> create table t1 (id int, r1 char(36)) tablespace innodb_file_per_table;
Query OK, 0 rows affected (0.04 sec)
单表空间除了解决之前说的系统表空间的几个缺点外，还有其他的优点，详细如下：
1. truncate table 操作比其他的任何表空间都快；
2. 可以把不同的表按照使用场景指定在不同的磁盘目录；
比如日志表放在慢点的磁盘，把需要经常随机读的表放在 SSD 上等。
mysql> create table ytt_dedicated (id int) data directory = '/var/lib/mysql-files';
Query OK, 0 rows affected (0.04 sec)3. 可以用 optimize table 来收缩或者重建经常增删改查的表。一般过程是这样的：建立和原来表一样的表结构和数据文件，把真实数据复制到临时文件，再删掉原始表定义和数据文件，最后把临时文件的名字改为和原始表一样的。
三、通用表空间
通用表空间先是出现在 MySQL Cluster 里，也就是 NDB 引擎。从 MySQL 5.7 引入到 InnoDB 引擎。通用表空间和系统表空间一样，也是共享表空间。每个表空间可以包含一张或者多张表，也就是说通用表空间和表之间是一对多的关系。
‘陆’ hdfs文件系统可以代替mysql吗
不能。
不是一个概念。mysql是传统的关系型数据库。hdfs是nosql hadoop的存储方式。hdfs是分布式的自带高可用存储，文件格式跟mysql的存储引擎不一样。大数据离线存储，当然是hdfs更合适。通过Map/Rece进行批处理递送到Apache Hadoop仍然是中枢环节。但随着要从“超思维速度“分析方面获取竞争优势的压力递增，因此Hadoop(分布式文件系统)自身经历重大的发展。
科技的发展允许实时查询，如Apache Drill, Cloudera Impala和Stinger Initiative正脱颖而出，新一代的资源管理Apache YARN 支持这些。为了支持这种日渐强调实时性操作,我们正发布一个新MySQL Applier for Hadoop(用于Hadoop的MySQL Applier)组件。它能够把MySQL中变化的事务复制到Hadoop / Hive / HDFS。Applier 组件补充现有基于批处理Apache Sqoop的连接性。
‘柒’ docker restart、start、stop与容器文件系统
大概是在2016/10前后，我们部门使用docker一段时间后偶尔会出现docker exec ... 无法进入容器的问题，环境为centos7.2、docker1.12.6，docker存储引擎为devicemapper，经过排查发现容器对应的文件系统已经umount，且发现开发同学用了大量的docker restart ... 操作。于是产生docker restart导致容器文件系统umount的疑问，后面对docker restart、start、stop三个命令与容器文件系统关系做了研究，以下是研究的记录。
通过docker run启动一个容器后，docker会同时挂载该容器的内存文件系统与容器的根文件系统（rootfs），比如
若容器的根文件系统（rootfs）umount，执行 docker exec -it xxx /bin/bash or /bin/sh会触发异常：
同时执行 docker restart xxx会触发异常：
分别查看docker restart、start、stop三个命令的debug信息，这里的实践环境为：centos7.2、docker1.12.6、存储引擎（storage-driver）:devicemapper、镜像：nginx:1.12
通过上面的日志输出可以了解到
分析发现，docker restart命令并不是stop、start两个命令的顺序叠加，docker restart操作并不涉及容器文件系统的处理，开始怀疑的由于docker restart操作导致容器的文件系统处于umount状态此处没有找到证据，但为了保证容器的根文件系统与内存系统mount的正确性，推荐对一个容器的重启使用docker stop xxx 然后 docker start xxx，而非docker restart xxx。
‘捌’ hive使用hadoop的分布式文件系统什么作为存储引擎
使用hdfs作为分布式存储
‘玖’ 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