MySQL存儲引擎概述

時間 2019-11-07

標籤 mysql 存儲引擎概述欄目 MySQL 简体版

原文原文鏈接

目錄mysql

1、mysql存儲引擎概述

1.1 什麼是存儲引擎？

MySQL中的數據用各類不一樣的技術存儲在文件（或者內存）中。這些技術中的每一種技術都使用不一樣的存儲機制、索引技巧、鎖定水平而且最終提供普遍的不一樣的功能和能力。經過選擇不一樣的技術，你可以得到額外的速度或者功能，從而改善你的應用的總體功能。sql

例如，若是你在研究大量的臨時數據，你也許須要使用內存存儲引擎。內存存儲引擎可以在內存中存儲全部的表格數據。又或者，你也許須要一個支持事務處理的數據庫(以確保事務處理不成功時數據的回退能力)。shell

這些不一樣的技術以及配套的相關功能在MySQL中被稱做存儲引擎(也稱做表類型)。數據庫

MySQL默認配置了許多不一樣的存儲引擎，能夠預先設置或者在MySQL服務器中啓用。你能夠選擇適用於服務器、數據庫和表格的存儲引擎，以便在選擇如何存儲你的信息、如何檢索這些信息以及你須要你的數據結合什麼性能和功能的時候爲你提供最大的靈活性。編程

選擇如何存儲和檢索你的數據的這種靈活性是MySQL爲何如此受歡迎的主要緣由。其它數據庫系統 (包括大多數商業選擇)僅支持一種類型的數據存儲。緩存

遺憾的是，其它類型的數據庫解決方案採起的「一個尺碼知足一切需求」的方式意味着你要麼就犧牲一些性能，要麼你就用幾個小時甚至幾天的時間詳細調整你的數據庫。使用MySQL，咱們僅須要修改咱們使用的存儲引擎就能夠了。安全

1.2 mysql支持哪些存儲引擎？

mysql5.6支持的存儲引擎包括InnoDB、MyISAM、MEMORY、CSV、BLACKHOLE、FEDERATED、MRG_MYISAM、ARCHIVE、PERFORMANCE_SCHEMA。其中NDB和InnoDB提供事務安全表，其餘存儲引擎都是非事務安全表。服務器

2、各類存儲引擎的特性

2.1 概覽

MySQL服務器採用了多層設計和獨立模塊，插件式存儲引擎體系結構，容許將存儲引擎加載到正在運新的MySQL服務器中，圖中的Pluggable Storage Engines部分。採用MySQL服務器體系結構，因爲在存儲級別上（也就是Pluggable Storage Engines）提供了一致和簡單的應用模型和API，應用程序編程人員和DBA可再也不考慮全部的底層實施細節。所以，儘管不一樣的存儲引擎具備不一樣的能力，應用程序是與之分離的。存儲引擎就司職與文件系統打交道了。網絡

2.2 各類存儲引擎的特性

併發性：某些應用程序比其餘應用程序具備不少的顆粒級鎖定要求（如行級鎖定）。
事務支持：並不是全部的應用程序都須要事務，但對的確須要事務的應用程序來講，有着定義良好的需求，如ACID兼容等。
引用完整性：經過DDL定義的外鍵，服務器須要強制保持關聯數據庫的引用完整性。
物理存儲：它包括各類各樣的事項，從表和索引的總的頁大小，到存儲數據所需的格式，到物理磁盤。
索引支持：不一樣的應用程序傾向於採用不一樣的索引策略，每種存儲引擎一般有本身的編制索引方法，但某些索引方法（如B-tree索引）對幾乎全部的存儲引擎來講是共同的。
內存高速緩衝：與其餘應用程序相比，不一樣的應用程序對某些內存高速緩衝策略的響應更好，所以，儘管某些內存高速緩衝對全部存儲引擎來講是共同的（如用於用戶鏈接的高速緩衝，MySQL的高速查詢高速緩衝等），其餘高速緩衝策略僅當使用特殊的存儲引擎時才惟必定義。
性能幫助：包括針對並行操做的多I/O線程，線程併發性，數據庫檢查點，成批插入處理等。
其餘目標特性：可能包括對地理空間操做的支持，對特定數據處理操做的安全限制等。

以上要求會在不一樣的需求中予以體現，經過單獨一個系統實現是不可能的，以上特色有些自己就是相互矛盾的，魚和熊掌的問題。對以上內容作些選擇，造成的存儲引擎就是一個插件引擎了，某些特定的需求可使用。以下圖，部分現有的存儲引擎以及基本特色：架構

2.3 各類搜索引擎介紹

InnoDB：MySql 5.6 版本默認的存儲引擎。InnoDB 是一個事務安全的存儲引擎，它具有提交、回滾以及崩潰恢復的功能以保護用戶數據。InnoDB 的行級別鎖定以及 Oracle 風格的一致性無鎖讀提高了它的多用戶併發數以及性能。InnoDB 將用戶數據存儲在彙集索引中以減小基於主鍵的普通查詢所帶來的 I/O 開銷。爲了保證數據的完整性，InnoDB 還支持外鍵約束。

MyISAM：MyISAM既不支持事務、也不支持外鍵、其優點是訪問速度快，可是表級別的鎖定限制了它在讀寫負載方面的性能，所以它常常應用於只讀或者以讀爲主的數據場景。

Memory：在內存中存儲全部數據，應用於對非關鍵數據由快速查找的場景。Memory類型的表訪問數據很是快，由於它的數據是存放在內存中的，而且默認使用HASH索引，可是一旦服務關閉，表中的數據就會丟失

BLACKHOLE：黑洞存儲引擎，相似於 Unix 的 /dev/null，Archive 只接收但卻並不保存數據。對這種引擎的表的查詢經常返回一個空集。這種表能夠應用於 DML 語句須要發送到從服務器，但主服務器並不會保留這種數據的備份的主從配置中。

CSV：它的表真的是以逗號分隔的文本文件。CSV 表容許你以 CSV 格式導入導出數據，以相同的讀和寫的格式和腳本和應用交互數據。因爲 CSV 表沒有索引，你最好是在普通操做中將數據放在 InnoDB 表裏，只有在導入或導出階段使用一下 CSV 表。

NDB：(又名 NDBCLUSTER)——這種集羣數據引擎尤爲適合於須要最高程度的正常運行時間和可用性的應用。注意：NDB 存儲引擎在標準 MySql 5.6 版本里並不被支持。目前可以支持

MySql 集羣的版本有：基於 MySql 5.1 的 MySQL Cluster NDB 7.1；基於 MySql 5.5 的 MySQL Cluster NDB 7.2；基於 MySql 5.6 的 MySQL Cluster NDB 7.3。一樣基於 MySql 5.6 的 MySQL Cluster NDB 7.4 目前正處於研發階段。

Merge：容許 MySql DBA 或開發者將一系列相同的 MyISAM 表進行分組，並把它們做爲一個對象進行引用。適用於超大規模數據場景，如數據倉庫。

Federated：提供了從多個物理機上聯接不一樣的 MySql 服務器來建立一個邏輯數據庫的能力。適用於分佈式或者數據市場的場景。

Example：這種存儲引擎用以保存闡明如何開始寫新的存儲引擎的 MySql 源碼的例子。它主要針對於有興趣的開發人員。這種存儲引擎就是一個啥事也不作的 "存根"。你可使用這種引擎建立表，可是你沒法向其保存任何數據，也沒法從它們檢索任何索引。

3、經常使用存儲引擎及適用場景

InnoDB：用於事務處理應用程序，支持外鍵和行級鎖。若是應用對事物的完整性有比較高的要求，在併發條件下要求數據的一致性，數據操做除了插入和查詢以外，還包括不少更新和刪除操做，那麼InnoDB存儲引擎是比較合適的。InnoDB除了有效的下降由刪除和更新致使的鎖定，還能夠確保事務的完整提交和回滾，對於相似計費系統或者財務系統等對數據準確要求性比較高的系統都是合適的選擇。

MyISAM：若是應用是以讀操做和插入操做爲主，只有不多的更新和刪除操做，而且對事務的完整性、併發性要求不高，那麼能夠選擇這個存儲引擎。

Memory：將全部的數據保存在內存中，在須要快速定位記錄和其餘相似數據的環境下，能夠提供極快的訪問。Memory的缺陷是對錶的大小有限制，雖然數據庫由於異常終止的話數據能夠正常恢復，可是一旦數據庫關閉，存儲在內存中的數據都會丟失。

4、存儲引擎在mysql中的使用

4.1 存儲引擎相關sql語句

# 查看當前的默認存儲引擎:

mysql> show variables like "default_storage_engine";

# 查詢當前數據庫支持的存儲引擎

mysql> show engines \G;

4.2 指定存儲引擎建表

4.2.1 在建表時指定

mysql> create table ai(id bigint(12),name varchar(200)) ENGINE=MyISAM; 

mysql> create table country(id int(4),cname varchar(50)) ENGINE=InnoDB;

# 也可使用alter table語句，修改一個已經存在的表的存儲引擎。

mysql> alter table ai engine = innodb;

4.2.2 在配置文件中指定

# my.ini文件
[mysqld]
default-storage-engine=INNODB

5、mysql的工做流程

MySQL架構總共四層，在上圖中以虛線做爲劃分。
　　

最上層的服務並非MySQL獨有的，大多數給予網絡的客戶端/服務器的工具或者服務都有相似的架構。好比：鏈接處理、受權認證、安全等。
第二層的架構包括大多數的MySQL的核心服務。包括：查詢解析、分析、優化、緩存以及全部的內置函數（例如：日期、時間、數學和加密函數）。同時，全部的跨存儲引擎的功能都在這一層實現：存儲過程、觸發器、視圖等。
第三層包含了存儲引擎。存儲引擎負責MySQL中數據的存儲和提取。服務器經過API和存儲引擎進行通訊。這些接口屏蔽了不一樣存儲引擎之間的差別，使得這些差別對上層的查詢過程透明化。存儲引擎API包含十幾個底層函數，用於執行「開始一個事務」等操做。但存儲引擎通常不會去解析SQL（InnoDB會解析外鍵定義，由於其自己沒有實現該功能），不一樣存儲引擎之間也不會相互通訊，而只是簡單的響應上層的服務器請求。
第四層包含了文件系統，全部的表結構和數據以及用戶操做的日誌最終仍是以文件的形式存儲在硬盤上。