MySQL的架構(gòu)和歷史是怎樣的，針對(duì)這個(gè)問題，這篇文章詳細(xì)介紹了相對(duì)應(yīng)的分析和解答，希望可以幫助更多想解決這個(gè)問題的小伙伴找到更簡(jiǎn)單易行的方法。

成都創(chuàng)新互聯(lián)公司專注為客戶提供全方位的互聯(lián)網(wǎng)綜合服務(wù)，包含不限于網(wǎng)站建設(shè)、網(wǎng)站制作、玄武網(wǎng)絡(luò)推廣、重慶小程序開發(fā)、玄武網(wǎng)絡(luò)營(yíng)銷、玄武企業(yè)策劃、玄武品牌公關(guān)、搜索引擎seo、人物專訪、企業(yè)宣傳片、企業(yè)代運(yùn)營(yíng)等，從售前售中售后，我們都將竭誠(chéng)為您服務(wù)，您的肯定，是我們最大的嘉獎(jiǎng)；成都創(chuàng)新互聯(lián)公司為所有大學(xué)生創(chuàng)業(yè)者提供玄武建站搭建服務(wù)，24小時(shí)服務(wù)熱線：028-86922220，官方網(wǎng)址：chinadenli.net

MySQL架構(gòu)和歷史

1.處理和存儲(chǔ)分離的設(shè)計(jì)

MySQL最重要，最與眾不同的特性是它的可插拔式存儲(chǔ)引擎架構(gòu)（將查詢處理，系統(tǒng)任務(wù)，數(shù)據(jù)的存儲(chǔ)，提取相分離）。

2.架構(gòu)：

層級(jí)	作用	備注
連接層	連接處理，授權(quán)認(rèn)證等	RDMS共有設(shè)計(jì)
服務(wù)層	查詢解析，緩存，分析優(yōu)化，內(nèi)置函數(shù)，跨引擎功能	MySQL核心服務(wù)與功能，服務(wù)層未設(shè)計(jì)外鍵
引擎層	負(fù)責(zé)數(shù)據(jù)存儲(chǔ)與提取	底層函數(shù)，不會(huì)解析SQL，不同引擎直接不在此層級(jí)互相通信，僅響應(yīng)來自上層的請(qǐng)求。處理外鍵

3.優(yōu)化與執(zhí)行

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

優(yōu)化器不關(guān)心表使用什么引擎，但存儲(chǔ)引擎對(duì)優(yōu)化查詢是有影響的。

4.鎖

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

寫鎖是排他的，相互阻塞，在給定的時(shí)間內(nèi)，同一行數(shù)據(jù)，只能有一個(gè)用戶正在進(jìn)行寫入。

大多數(shù)時(shí)候，MySQL鎖的內(nèi)部管理都是透明的。

在給定的資源上，鎖定的數(shù)據(jù)量越少，則系統(tǒng)的并發(fā)讀越高。

加鎖需要消耗資源，如果系統(tǒng)花費(fèi)大量時(shí)間來管理鎖，而不是存取數(shù)據(jù)，則系統(tǒng)的性能可能會(huì)因此收到影響。

一般會(huì)在鎖的開銷和數(shù)據(jù)的安全性之間尋求平衡，即在表上施加行級(jí)鎖。

每種MySQL引擎都可以實(shí)現(xiàn)自己的鎖傾向和鎖粒度。

寫鎖比讀鎖有更高的優(yōu)先級(jí)，并發(fā)時(shí)，寫鎖請(qǐng)求可能會(huì)被插入到隊(duì)列的最前端，但讀鎖最多只能排在其他讀鎖的最前端。

服務(wù)層會(huì)對(duì)涉及到整個(gè)表的內(nèi)容的更改使用表級(jí)鎖，引擎層的鎖機(jī)制被忽略。

行級(jí)鎖只在存儲(chǔ)引擎層實(shí)現(xiàn)。

InnoDB采用兩段鎖定協(xié)議，在事務(wù)執(zhí)行過程中，隨時(shí)都可以執(zhí)行鎖定，但只有在整個(gè)事務(wù)提交或者回滾時(shí)才會(huì)同一時(shí)間釋放該事務(wù)占有的所有鎖?！[式鎖’

服務(wù)層可以使用LOCK TABLE或者UNLOCK TABLE，但可能會(huì)和事務(wù)產(chǎn)生相互影響產(chǎn)生不可預(yù)料的后果，盡量不要在業(yè)務(wù)進(jìn)行時(shí)中使用。

5.事務(wù)

事務(wù)就是一組原子性的SQL查詢，一組獨(dú)立的工作單元。事務(wù)內(nèi)的語句要么全部執(zhí)行完，要么全部失敗。

一個(gè)完備的數(shù)據(jù)庫(kù)系統(tǒng)需要滿足ACID特征：

Atomictiy 原子性：一個(gè)事務(wù)視為不可分割的最小單元。

Consistency 一致性: 數(shù)據(jù)庫(kù)總是從一個(gè)一致性的狀態(tài)轉(zhuǎn)換到另一個(gè)一致性的狀態(tài)。

    Isolation 隔離性: 一個(gè)事務(wù)所做的修改在最終提交之前，對(duì)其事務(wù)是不可見的。

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

一個(gè)實(shí)現(xiàn)了ACID特性的數(shù)據(jù)庫(kù)，需要更強(qiáng)的硬件。

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

非事務(wù)型的表只能自動(dòng)提交。

事務(wù)型的表在執(zhí)行DDL操作或者lock table時(shí)會(huì)強(qiáng)行commit當(dāng)前的活動(dòng)事務(wù)

隔離級(jí)別（ANSI）

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

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

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

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

可以通過set [session] transaction isolation level [RU|RC|RR|SX]設(shè)置隔離級(jí)別，全局性設(shè)置在下一個(gè)事務(wù)開始時(shí)生效，會(huì)話級(jí)設(shè)置只對(duì)當(dāng)前事務(wù)有效

隔離級(jí)別	臟讀可能性	不可重復(fù)讀	幻讀可能性	加鎖讀
RU	Y	Y	Y	N
RC	N	Y	Y	N
RR	N	N	Y	N
SX	N	N	N	Y

死鎖

兩個(gè)或以上的事務(wù)爭(zhēng)用同一組資源，并請(qǐng)求鎖定對(duì)方占用的資源。

處理辦法：完備的RDMS包含了死鎖檢測(cè)與死鎖超時(shí)機(jī)制。

InnoDB:將持有最少行級(jí)X鎖的事務(wù)進(jìn)行回滾。

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

事務(wù)日志（redo）

可以提高事務(wù)的效率，存儲(chǔ)引擎在修改表的數(shù)據(jù)時(shí)只需要修改其內(nèi)存拷貝，再批量地把修改的行為記錄到硬盤上的事務(wù)日志文件中。

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

6.多版本并發(fā)控制（MVCC）

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

MVCC是通過保存數(shù)據(jù)行在某個(gè)時(shí)間點(diǎn)的快照來實(shí)現(xiàn)的。

根據(jù)事務(wù)開始時(shí)間的不同，每個(gè)事務(wù)對(duì)同一張表，同一時(shí)刻看到的數(shù)據(jù)可能是不一樣的。

InnoDB的MVCC，是通過在每個(gè)記錄（包括已經(jīng)存入undo中的記錄）后面保存兩個(gè)隱藏的版本號(hào)來實(shí)現(xiàn)的。即：該數(shù)據(jù)創(chuàng)建時(shí)的系統(tǒng)版本號(hào)和該數(shù)據(jù)失效時(shí)的系統(tǒng)版本號(hào)。

其他事務(wù)：

SELECT時(shí)：只查找比當(dāng)前事務(wù)創(chuàng)建更早的行（極端情況下，在此事務(wù)中對(duì)此行進(jìn)行了修改或創(chuàng)建，即讀取本事務(wù)中被修改后此行的數(shù)據(jù)）。

INSERT時(shí)：為新插入的此行保存本事務(wù)版本的版本號(hào)作為此行的創(chuàng)建版本號(hào)。同時(shí)若在此事務(wù)中不在對(duì)此行進(jìn)行修改，則行過期版本號(hào)留空

DELETE時(shí)：將本事務(wù)的版本號(hào)賦給被刪除行的失效版本號(hào)

UPDATE時(shí)：將本事務(wù)的版本號(hào)賦給被修改行的失效版本號(hào)，同時(shí)插入被修改后的數(shù)據(jù)，同時(shí)把本事務(wù)的版本號(hào)付給新插入的修改后的數(shù)據(jù)的創(chuàng)建版本號(hào)。

保留這兩個(gè)額外版本號(hào)，可以使大多數(shù)讀操作都不用加S鎖，但這些多余的行會(huì)占用undo空間。建議將undo從共享表空間中獨(dú)立出來，并減小事務(wù)長(zhǎng)度。

7.存儲(chǔ)引擎

不同引擎保存數(shù)據(jù)和索引的方式是不同的，但表的定義是在服務(wù)層統(tǒng)一處理的。

通過show table status顯示表的相關(guān)信息

屬性	屬性值	說明
Name:	user	表名
Engine:	InnoDB	存儲(chǔ)引擎
Row_format:	Dynamic	行格式，變長(zhǎng)行
Rows	3	對(duì)應(yīng)InnoDB，估計(jì)的行數(shù)值
Avg_row_length	5461	平均每行字節(jié)數(shù)
Data_length	16384	表數(shù)據(jù)字節(jié)數(shù)
Max_data_length	0	表最大字節(jié)數(shù)（InnoDB無限制）
Index_length	0	非主鍵索引占用字節(jié)數(shù)
Data_free	4194304	已分配但未使用的字節(jié)數(shù)
Auto_increment	NULL	下個(gè)自增值的起始點(diǎn)
Create_time	2018-01-24 20:02:01	創(chuàng)建時(shí)間
Update_time	NULL	最后一次的更新時(shí)間
Check_time	NULL	CHECK TABLE命令使用的時(shí)間
Collation	utf8_bin	該表默認(rèn)字符集與排序規(guī)則
Checksum	NULL	（若啟用校驗(yàn)）校驗(yàn)和
Create_options	stats_persistent=0	建表時(shí)的其他非默認(rèn)選項(xiàng)
Comment	Users and privileges	表的備注

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

InnoDB引擎一直朝著可測(cè)量性，可擴(kuò)展性，可配置化，性能，更多新特性的方向演進(jìn)。

InnoDB引擎概覽

InnoDB的數(shù)據(jù)存儲(chǔ)在表空間中，推薦使用獨(dú)立表空間，即將各個(gè)表的數(shù)據(jù)和索引放在單獨(dú)的文件中。

InnoDB使用MVCC來支持高并發(fā)，并且實(shí)現(xiàn)了四個(gè)標(biāo)準(zhǔn)的隔離級(jí)別。默認(rèn)隔離級(jí)別為可重復(fù)讀RR，并且通過間隙鎖的機(jī)制解決了范圍讀可能因?yàn)樾虏迦胫祵?dǎo)致出現(xiàn)幻讀的問題。

間隙鎖通過在本來鎖定查詢?cè)O(shè)計(jì)的行同事，還會(huì)對(duì)索引中的間隙進(jìn)行鎖定，防止插入新的行。

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

InnoDB引擎表的文件存儲(chǔ)格式是獨(dú)立的，某種程度上可以跨平臺(tái)使用。

InnoDB的顯著優(yōu)化特點(diǎn)：從磁盤讀取數(shù)據(jù)時(shí)的可預(yù)測(cè)性讀，引入了能夠在內(nèi)存中創(chuàng)建Hash索引來加速讀操作的自適應(yīng)哈希索引（adaptive hash index），能夠加速插入操作的插入緩沖區(qū)(insert buffer，對(duì)非主鍵非唯一性索引進(jìn)行緩存，每10s合并到非主鍵索引中)。

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

有趣的CSV引擎

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

慢慢棄用的引擎：

Federated引擎，本來設(shè)計(jì)用于建立Oracle，SQL server到MySQL的數(shù)據(jù)聯(lián)系紐帶，后被用于創(chuàng)建跨實(shí)例連接（類似于SQL server中的同義詞或者鏈接服務(wù)器），但經(jīng)常帶來問題，默認(rèn)禁用，MariaDB提供了一個(gè)改進(jìn)版的FederatedX。

Memory引擎，數(shù)據(jù)只存在內(nèi)存中，重啟后表結(jié)構(gòu)留存，但數(shù)據(jù)會(huì)全部丟失。支持HASH索引，表級(jí)鎖，并發(fā)低，行長(zhǎng)度固定。

第三方常用存儲(chǔ)引擎：

XtraDB引擎，Percona公司基于InnoDB引擎的改進(jìn)版本

TokuDB引擎，基于分形樹索引的引擎，具有較高的壓縮比，可以在很大的數(shù)據(jù)量上創(chuàng)建索引。

Infobright引擎，列組織的引擎，面向大數(shù)據(jù)設(shè)計(jì)。

更改表的存儲(chǔ)引擎：alter table t1 engine = InnoDB; 執(zhí)行過程中會(huì)創(chuàng)建相同表結(jié)構(gòu)不同引擎的一張新表，然后按行將數(shù)據(jù)從原表讀入到新表中，會(huì)進(jìn)行鎖表，消耗大量系統(tǒng)IO，盡量不要在業(yè)務(wù)高峰期進(jìn)行，或者使用pt-online-schema-change的工具進(jìn)行在線修改。

關(guān)于MySQL的架構(gòu)和歷史是怎樣的問題的解答就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道了解更多相關(guān)知識(shí)。

分享文章：MySQL的架構(gòu)和歷史是怎樣的
網(wǎng)站地址：http://chinadenli.net/article14/ihdhge.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供Google、定制開發(fā)、品牌網(wǎng)站制作、網(wǎng)站建設(shè)、定制網(wǎng)站、網(wǎng)站收錄

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)