首先創建表
我們能夠看到，表是不支持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