MySQL的架構和歷史是怎樣的

MySQL的架構和歷史是怎樣的，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

MySQL架構和歷史

1.處理和存儲分離的設計

MySQL最重要，最與眾不同的特性是它的可插拔式存儲引擎架構（將查詢處理，系統任務，數據的存儲，提取相分離）。

2.架構：

3.優化與執行

服務層解析查詢，創建解析樹，然后進行重寫查詢，決定表的讀取順序，選擇合適的索引等。在此步，用戶可以通過hint關鍵字或者force index影響優化器的決策，也可以通過explain命令查看優化器如何優化決策。

優化器不關心表使用什么引擎，但存儲引擎對優化查詢是有影響的。

4.鎖

讀鎖是共享的，相互不阻塞。

寫鎖是排他的，相互阻塞，在給定的時間內，同一行數據，只能有一個用戶正在進行寫入。

大多數時候，MySQL鎖的內部管理都是透明的。

在給定的資源上，鎖定的數據量越少，則系統的并發讀越高。

加鎖需要消耗資源，如果系統花費大量時間來管理鎖，而不是存取數據，則系統的性能可能會因此收到影響。

一般會在鎖的開銷和數據的安全性之間尋求平衡，即在表上施加行級鎖。

每種MySQL引擎都可以實現自己的鎖傾向和鎖粒度。

寫鎖比讀鎖有更高的優先級，并發時，寫鎖請求可能會被插入到隊列的最前端，但讀鎖最多只能排在其他讀鎖的最前端。

服務層會對涉及到整個表的內容的更改使用表級鎖，引擎層的鎖機制被忽略。

行級鎖只在存儲引擎層實現。

InnoDB采用兩段鎖定協議，在事務執行過程中，隨時都可以執行鎖定，但只有在整個事務提交或者回滾時才會同一時間釋放該事務占有的所有鎖。‘隱式鎖’

服務層可以使用LOCK TABLE或者UNLOCK TABLE，但可能會和事務產生相互影響產生不可預料的后果，盡量不要在業務進行時中使用。

5.事務

事務就是一組原子性的SQL查詢，一組獨立的工作單元。事務內的語句要么全部執行完，要么全部失敗。

一個完備的數據庫系統需要滿足ACID特征：

Atomictiy 原子性：一個事務視為不可分割的最小單元。

Consistency 一致性: 數據庫總是從一個一致性的狀態轉換到另一個一致性的狀態。

    Isolation 隔離性: 一個事務所做的修改在最終提交之前，對其事務是不可見的。

Durability 持久性：一旦提交，永久保存，不受系統崩潰影響。

一個實現了ACID特性的數據庫，需要更強的硬件。

即使存儲引擎不支持事務，但還可以通過lock table來提供部分ACID特性。

非事務型的表只能自動提交。

事務型的表在執行DDL操作或者lock table時會強行commit當前的活動事務

隔離級別（ANSI）

READ UNCOMMITED(未提交讀)：事務中未提交的修改也會被其他事務讀到，’臟讀‘，性能不會好太多。

READ COMMITED(提交讀)：事務中提交后的修改會被其他事務讀到,但會造成不可重復讀。MSSQL,ORACLE

READ REPEATABLE(可重復讀):事務中多次讀取同一條數據值相同，但新插入的不算，即主鍵范圍讀可能不一致，'幻讀',MySQL默認級別。

SEARIALIZE(串行)：取消并行，完全串行，悲觀鎖。

可以通過set [session] transaction isolation level [RU|RC|RR|SX]設置隔離級別，全局性設置在下一個事務開始時生效，會話級設置只對當前事務有效

死鎖

兩個或以上的事務爭用同一組資源，并請求鎖定對方占用的資源。

處理辦法：完備的RDMS包含了死鎖檢測與死鎖超時機制。

InnoDB:將持有最少行級X鎖的事務進行回滾。

死鎖在事務型RDMS中是無法避免的，死鎖發生后，只有部分或者完全回滾其中一個事務才能打破窘境。

事務日志（redo）

可以提高事務的效率，存儲引擎在修改表的數據時只需要修改其內存拷貝，再批量地把修改的行為記錄到硬盤上的事務日志文件中。

事務日志采用了正向追加的方式，保證了寫入時的 順序IO。批量記錄修改的行為時，事務日志持久后，可以在后臺將內存中的數據慢慢刷回磁盤

6.多版本并發控制（MVCC）

MVCC是行級鎖的一個變種，在很多情況下避免了加鎖的操作，且只在RR和RC隔離級別下工作。

MVCC是通過保存數據行在某個時間點的快照來實現的。

根據事務開始時間的不同，每個事務對同一張表，同一時刻看到的數據可能是不一樣的。

InnoDB的MVCC，是通過在每個記錄（包括已經存入undo中的記錄）后面保存兩個隱藏的版本號來實現的。即：該數據創建時的系統版本號和該數據失效時的系統版本號。

其他事務：

SELECT時：只查找比當前事務創建更早的行（極端情況下，在此事務中對此行進行了修改或創建，即讀取本事務中被修改后此行的數據）。

INSERT時：為新插入的此行保存本事務版本的版本號作為此行的創建版本號。同時若在此事務中不在對此行進行修改，則行過期版本號留空

DELETE時：將本事務的版本號賦給被刪除行的失效版本號

UPDATE時：將本事務的版本號賦給被修改行的失效版本號，同時插入被修改后的數據，同時把本事務的版本號付給新插入的修改后的數據的創建版本號。

保留這兩個額外版本號，可以使大多數讀操作都不用加S鎖，但這些多余的行會占用undo空間。建議將undo從共享表空間中獨立出來，并減小事務長度。

7.存儲引擎

不同引擎保存數據和索引的方式是不同的，但表的定義是在服務層統一處理的。

通過show table status顯示表的相關信息

InnoDB引擎被設計用來處理大量短期事務（大部分情況下正常提交），正常情況下默認使用InnoDB引擎，MySQL8.0版本，將mysql庫中的表也從MyISAM更換為InnoDB引擎。

InnoDB引擎一直朝著可測量性，可擴展性，可配置化，性能，更多新特性的方向演進。

InnoDB引擎概覽

InnoDB的數據存儲在表空間中，推薦使用獨立表空間，即將各個表的數據和索引放在單獨的文件中。

InnoDB使用MVCC來支持高并發，并且實現了四個標準的隔離級別。默認隔離級別為可重復讀RR，并且通過間隙鎖的機制解決了范圍讀可能因為新插入值導致出現幻讀的問題。

間隙鎖通過在本來鎖定查詢設計的行同事，還會對索引中的間隙進行鎖定，防止插入新的行。

InnoDB表是基于聚簇索引建立的，即索引組織表。這種設計，使得對主鍵的進行的查詢效率很高。其二級索引，即非聚集索引（普通索引，非主鍵索引）是通過鏈接的方式指向其對應的主鍵位置，即二級索引中包含了主鍵列。這就會產生一個主鍵列長度很大，其他索引的大小也會同樣很大的問題。這個特性要求我們主鍵列的最大長度盡量減小。

InnoDB引擎表的文件存儲格式是獨立的，某種程度上可以跨平臺使用。

InnoDB的顯著優化特點：從磁盤讀取數據時的可預測性讀，引入了能夠在內存中創建Hash索引來加速讀操作的自適應哈希索引（adaptive hash index），能夠加速插入操作的插入緩沖區(insert buffer，對非主鍵非唯一性索引進行緩存，每10s合并到非主鍵索引中)。

InnoDB引擎的表支持熱物理備份（非邏輯備份成sql文件）即XtraBackup或者官方的Enterprise Backup

有趣的CSV引擎

可以將Excel文件另存為CSV格式，放入MySQL數據目錄下，即可在MySQL中打開使用。

慢慢棄用的引擎：

Federated引擎，本來設計用于建立Oracle，SQL server到MySQL的數據聯系紐帶，后被用于創建跨實例連接（類似于SQL server中的同義詞或者鏈接服務器），但經常帶來問題，默認禁用，MariaDB提供了一個改進版的FederatedX。

Memory引擎，數據只存在內存中，重啟后表結構留存，但數據會全部丟失。支持HASH索引，表級鎖，并發低，行長度固定。

第三方常用存儲引擎：

XtraDB引擎，Percona公司基于InnoDB引擎的改進版本

TokuDB引擎，基于分形樹索引的引擎，具有較高的壓縮比，可以在很大的數據量上創建索引。

Infobright引擎，列組織的引擎，面向大數據設計。

更改表的存儲引擎：alter table t1 engine = InnoDB; 執行過程中會創建相同表結構不同引擎的一張新表，然后按行將數據從原表讀入到新表中，會進行鎖表，消耗大量系統IO，盡量不要在業務高峰期進行，或者使用pt-online-schema-change的工具進行在線修改。

關于MySQL的架構和歷史是怎樣的問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。