㈠ 常見的存儲引擎種類
常見的存儲引擎種類
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