1.1 MySQL邏輯架構(gòu)
MySQL服務(wù)器邏輯架構(gòu)圖.png
最上層的不是MySQL所獨(dú)有的，大多數(shù)是基于網(wǎng)絡(luò)的客戶端/服務(wù)器的工具或者服務(wù)都有類似的架構(gòu)。比如鏈接處理、授權(quán)認(rèn)證、安全等等。
第二層架構(gòu)MySQL的核心服務(wù)功能，包括查詢解析、分析、優(yōu)化、緩存以及所有的內(nèi)置函數(shù)，所有跨存儲(chǔ)引擎的功能都在這實(shí)現(xiàn)的:存儲(chǔ)過程、觸發(fā)器、視圖等。
第三層包含了存儲(chǔ)引擎。存儲(chǔ)引擎負(fù)責(zé)MySQL中數(shù)據(jù)的存儲(chǔ)和提取。服務(wù)器通過API與存儲(chǔ)引擎進(jìn)行通信，API屏蔽了不同的存儲(chǔ)引擎之間的差異。存儲(chǔ)引擎包含幾十個(gè)底層函數(shù)，用于執(zhí)行諸如"開始一個(gè)事務(wù)"或者"根據(jù)主鍵提取一行記錄"等操作。但存儲(chǔ)引擎不會(huì)去解析SQL，不同存儲(chǔ)引擎之間不會(huì)相互通信，而只是簡(jiǎn)單地響應(yīng)上層服務(wù)的請(qǐng)求。
1.2 并發(fā)控制
1.2.2 鎖粒度
表鎖(table lock) 是MySQL中最基本的鎖策略，并且是開銷最小的策略，它會(huì)鎖定整張表。一個(gè)用戶在對(duì)表進(jìn)行寫操作前，需要先獲得寫鎖，這回阻塞其他用戶對(duì)該表的所有讀寫操作。只有沒有寫鎖時(shí)，其他讀取的用戶才能獲得讀鎖。
寫鎖比讀鎖有更高的優(yōu)先級(jí)，一個(gè)寫鎖請(qǐng)求可能會(huì)被插入到讀鎖隊(duì)列的前面(寫鎖可以插入到鎖隊(duì)列中讀鎖的前面，反之讀鎖不能插入到寫鎖的前面)。
盡管存儲(chǔ)引擎可以管理自己的鎖，MySQL本身還是會(huì)使用各種有效的表鎖來實(shí)現(xiàn)不同的目的。例如ALTER TABLE之類的語(yǔ)句使用表鎖此時(shí)會(huì)覆蓋存儲(chǔ)引擎的鎖機(jī)制。
行級(jí)鎖(row lock)可以最大程度的支持并發(fā)處理(同時(shí)也帶了最大的鎖開銷)。眾所周知，在InnoDB和XtraDB，以及其他一些存儲(chǔ)引擎中實(shí)現(xiàn)了行級(jí)鎖，行級(jí)鎖只在存儲(chǔ)引擎層實(shí)現(xiàn)，而MySQL的服務(wù)層沒有實(shí)現(xiàn)。
1.3 事務(wù)
事務(wù)就是一組原子性的SQL查詢，或者說一個(gè)獨(dú)立的工作單元。事務(wù)內(nèi)的語(yǔ)句要么全部執(zhí)行，只要有一條失敗，所有語(yǔ)句都不會(huì)執(zhí)行?？梢杂肧TART TRANSACTION 開始一個(gè)事務(wù)，然后用COMMIT 提交事務(wù)將修改的數(shù)據(jù)持久化保存，或者用ROLLBAK撤銷所有修改。
1.3.1 隔離級(jí)別
隔離性其實(shí)比想象中的復(fù)雜。在SQL標(biāo)準(zhǔn)中定義了四種隔離級(jí)別，每一種級(jí)別都規(guī)定了一個(gè)事務(wù)中所做的修改，哪些在事務(wù)內(nèi)和事務(wù)間是可見的，哪些是不可見的。較低級(jí)別的隔離通?？梢詧?zhí)行更高的并發(fā)，系統(tǒng)的開銷也更低。
- READ UNCOMMITTED :
在未提交讀級(jí)別，事務(wù)中的修改，即使沒有提交，對(duì)其他事務(wù)也都是可見的。事務(wù)讀取未提交的數(shù)據(jù)，稱為臟讀(Dirty Read)。從性能上說，READ UNCOMMITTED不會(huì)比其它級(jí)別好太多，但缺乏其他級(jí)別很多好處，實(shí)際應(yīng)用中一般很少使用。
- READ COMMITTED :
提交讀滿足隔離性的簡(jiǎn)單定義:一個(gè)事務(wù)開始，只能“看見”已經(jīng)提交的事務(wù)所做的修改。這個(gè)級(jí)別有時(shí)候也叫做不可重復(fù)讀(nonrepeatable read)，因?yàn)閮纱螆?zhí)行同樣的查詢，可能會(huì)得到不一樣的效果。
- REPEATABLE READ :
可重復(fù)讀解決了臟讀的問題。該級(jí)別保證了同一個(gè)事物多次讀取同樣記錄的結(jié)果是一致的。但是無法解決幻讀，幻讀指的是當(dāng)某個(gè)事務(wù)在讀取某個(gè)范圍內(nèi)的記錄時(shí)，另一個(gè)事務(wù)又在該范圍內(nèi)插入新的記錄，之前的事務(wù)再次讀取會(huì)產(chǎn)生幻行(Phantom Row)。InnoDB和XtraDB存儲(chǔ)引擎通過多版本冰法控制(MVCC,Multiversion Concurrency Control) 解決了幻讀的問題?？芍貜?fù)讀也是MySQL的默認(rèn)事務(wù)隔離級(jí)別。
- SERIALIZABLE
可串行化是最高的隔離級(jí)別。強(qiáng)制事務(wù)串行執(zhí)行，避免了前面說的幻讀問題。SERIALIZABLE會(huì)在讀取的每一行數(shù)據(jù)上都加鎖，所以可能導(dǎo)致大量的超時(shí)和鎖晶振問題。實(shí)際應(yīng)用中只有在非常需要確保數(shù)據(jù)一致性而且可以接受沒有并發(fā)的情況下考慮采用該級(jí)別。
Isolation.png
1.3.3 事務(wù)日志
使用事務(wù)日志，存儲(chǔ)引擎在修改表的數(shù)據(jù)時(shí)只需要修改其內(nèi)存拷貝，再把該修改行為記錄到持久在硬盤上的事務(wù)日志中。事務(wù)日志采用的是追加的方式。因此寫日志的操作是磁盤上的一小塊區(qū)域內(nèi)的順序I/O,而不像隨機(jī)I/O需要在磁盤的多個(gè)地方移動(dòng)磁頭，所以采用事務(wù)日志的方式相對(duì)來說要快得多。事務(wù)日志持久以后，內(nèi)存中修改的數(shù)據(jù)在后灘可以慢慢刷回到磁盤。目前大多數(shù)存儲(chǔ)引擎都是這樣實(shí)現(xiàn)的，我們通常稱之為預(yù)寫式日志(Write-Ahead Logging)，修改數(shù)據(jù)需要寫兩次磁盤。
如果數(shù)據(jù)的修改已經(jīng)記錄到事務(wù)日志并持久化，但數(shù)據(jù)本身還沒有寫回磁盤，此時(shí)系統(tǒng)崩潰，存儲(chǔ)引擎在重啟時(shí)能夠自動(dòng)回復(fù)這部分修改的數(shù)據(jù)。具體的回復(fù)方式則視存儲(chǔ)引擎而定。
1.3.4 MySQL中的事務(wù)
- AUTOCOMMIT
MySQL默認(rèn)采用自動(dòng)提交(AUTOCOMMIT)模式。也就是說如果不是現(xiàn)實(shí)的開始一個(gè)事務(wù)，則每個(gè)查詢都被當(dāng)做一個(gè)事務(wù)提交操作。
另外，像一些ALTER TABLE 這種DDL、LOCK TABLES等會(huì)強(qiáng)制執(zhí)行COMMIT提交當(dāng)前的活動(dòng)事務(wù)。MySQL可以通過SET TRANSACTION ISOLATION LEVEL命令來設(shè)置隔離級(jí)別。新的隔離級(jí)別會(huì)在下次事務(wù)開始生效。
- 隱式和顯示的鎖定
InnoDB采用的是兩階段鎖定協(xié)議(two-phase locking protocol).在事務(wù)執(zhí)行過程中，隨時(shí)可以執(zhí)行鎖定，只有在COMMIT和ROLLBACK的時(shí)候才會(huì)釋放，并且所有鎖在同一時(shí)刻釋放。前面描述的鎖定都是隱式鎖定，InnoDB根據(jù)隔離級(jí)別在需要的時(shí)候自動(dòng)加鎖。
另外，InnoDB也支持通過語(yǔ)句顯示鎖定，這些事MySQL范疇的語(yǔ)句，不屬于SQL規(guī)范:
SELECT ... LOCK IN SHARE MODE
SELECT ... FOR UPDATE
MySQL支持LOCK TABLES 和 UNLOCK TABLES語(yǔ)句，這是在服務(wù)器層實(shí)現(xiàn)的，和存儲(chǔ)引擎無關(guān)。他們有自己的用途，并不能替代事務(wù)處理，還是要依賴事務(wù)性存儲(chǔ)引擎來實(shí)現(xiàn)事務(wù)。如果一個(gè)線程在一個(gè)表上得到一個(gè)寫鎖，哪么只有這個(gè)線程可以從表中讀取和寫表，其他線程阻塞；若獲得是讀鎖，那么所有線程只讀，不能寫。
LOCK TABLES和事務(wù)之間相互影響的話，情況會(huì)變得非常復(fù)雜。因此建議，除了事務(wù)中禁用了AUTOCOMMIT，可以使用LOCK TABLES之外，其他任何時(shí)候都不要顯示的執(zhí)行LOCK TABLES。
1.4 多版本并發(fā)控制
MySQL 大多數(shù)事務(wù)性存儲(chǔ)引擎都不是簡(jiǎn)單的行級(jí)鎖，他們一般都實(shí)現(xiàn)了多版本并發(fā)控制(MVCC)?？梢哉J(rèn)為MVCC是行級(jí)鎖的一個(gè)變種，但是它很多情況下避免了加鎖操作，因此開銷更低，不同數(shù)據(jù)庫(kù)的實(shí)現(xiàn)機(jī)制有所不同，但大都實(shí)現(xiàn)了非阻塞的讀操作，寫操作也只鎖定必要的行。通過保存數(shù)據(jù)在某個(gè)時(shí)間點(diǎn)的快照來實(shí)現(xiàn)，根據(jù)事務(wù)開始的時(shí)間不同，每個(gè)事務(wù)對(duì)同一張表同一時(shí)刻看到的數(shù)據(jù)可能會(huì)不一樣。
InnoDB的MVCC，是通過在每行記錄后面保存兩個(gè)隱藏的列來實(shí)現(xiàn)的。這兩個(gè)列，一個(gè)保存了行的創(chuàng)建時(shí)間，一個(gè)保存行的過期時(shí)間(或刪除時(shí)間)。當(dāng)然存儲(chǔ)的并不是實(shí)際的時(shí)間值，而是系統(tǒng)版本號(hào)。每開始一個(gè)新的事務(wù)，系統(tǒng)版本號(hào)都會(huì)自動(dòng)遞增，同時(shí)作為事務(wù)的版本號(hào)，用來和查詢到的每行記錄的版本號(hào)進(jìn)行比較，下面看一下REPEATABLE READ隔離級(jí)別下MVCC具體實(shí)現(xiàn):
- SELECT
InooDB會(huì)根據(jù)以下兩個(gè)條件檢查每行記錄:
a. InnoDB只查找版本早于當(dāng)前事務(wù)版本的數(shù)據(jù)航(即行的系統(tǒng)版本號(hào)小于或等于事務(wù)的系統(tǒng)版本號(hào))，這樣可以確保事務(wù)讀取的行要么是在事務(wù)開始前存在的，要么是事務(wù)自身插入或修改過的。
b. 行的刪除版本要么未定義，要么大于當(dāng)前事務(wù)版本號(hào)。這可以確保事務(wù)讀取到的行，在事務(wù)開始之前未刪除。
只有符合以上兩個(gè)條件的記錄，才能返回作為查詢的結(jié)果。- INSERT:
InnoDB為新插入的每一行保存當(dāng)前系統(tǒng)版本號(hào)作為行版本號(hào)。- DELETE:
InooDB為刪除的每一行保存當(dāng)前系統(tǒng)版本號(hào)作為行刪除標(biāo)識(shí)。- UPDATE:
InnoDB為插入一行新紀(jì)錄，保存當(dāng)前系統(tǒng)版本號(hào)作為行版本號(hào)，同時(shí)保存當(dāng)前系統(tǒng)版本號(hào)到原來的行作為航刪除標(biāo)識(shí)。
保存這兩個(gè)系統(tǒng)版本號(hào)，使大多數(shù)操作不用加鎖。這樣設(shè)計(jì)使得讀數(shù)據(jù)操作很簡(jiǎn)單，性能很好，并且也能保證只會(huì)讀取到符合標(biāo)準(zhǔn)的行。不足之處是每行記錄都需要額外的存儲(chǔ)空間，做額外的行檢查和維護(hù)工作。
MVCC只在REPEATABLE READ和READ COMMITTED兩個(gè)隔離級(jí)別下工作。其他兩個(gè)隔離級(jí)別都和MVCC不兼容，READ UNCOMMITTED總是讀取最新的數(shù)據(jù)行，而SERIALIZABLE則會(huì)對(duì)所有讀取的行都加鎖。
1.5 MySQL的存儲(chǔ)引擎
在文件系統(tǒng)中，MySQL將每個(gè)數(shù)據(jù)庫(kù)保存為數(shù)據(jù)目錄下的一個(gè)子目錄。創(chuàng)建表時(shí)，MySQl會(huì)在數(shù)據(jù)庫(kù)子目錄下創(chuàng)建一個(gè)和表同名的.frm文件保存表的定義。可以用show table status 顯示表的相關(guān)信息:
mysql> show table status like 'user' \G
*************************** 1. row ***************************
Name: user #表名
Engine: MyISAM #存儲(chǔ)引擎類型
Version: 10
Row_format: Dynamic #行的格式
Rows: 7 #表中的行數(shù)
Avg_row_length: 116 #平均每行包括的字節(jié)數(shù)
Data_length: 812 #表數(shù)據(jù)的大小
Max_data_length: 281474976710655 #表數(shù)據(jù)的最大容量
Index_length: 2048 #索引的大小
Data_free: 0 #對(duì)于MyISAM表標(biāo)識(shí)已分配但未使用的空間
Auto_increment: NULL #下一個(gè)AUTO_INCREMENT的值
Create_time: 2018-11-08 17:53:35 #表的創(chuàng)建時(shí)間
Update_time: 2018-11-08 18:26:30 #表的數(shù)據(jù)最后修改時(shí)間
Check_time: NULL #最后一次檢查表的時(shí)間
Collation: utf8_bin #表的默認(rèn)字符集和字符排列順序規(guī)則
Checksum: NULL #如果啟用保存的是整個(gè)表的實(shí)時(shí)校驗(yàn)和
Create_options: //創(chuàng)建表時(shí)指定的其他選項(xiàng)
Comment: Users and global privileges #其他一些額外信息
1 row in set (0.00 sec)
1.5.1 InnoDB存儲(chǔ)引擎
InnoDB的數(shù)據(jù)存儲(chǔ)在表空間中，在MySQL4.1以后InnoDB將每個(gè)表的數(shù)據(jù)和索引文件存放在單獨(dú)的文件中。
InnoDB采用MVCC來支持高并發(fā)，并且實(shí)現(xiàn)了四個(gè)標(biāo)準(zhǔn)的隔離級(jí)別。其默認(rèn)級(jí)別是REPEATABLE READ,并且通過間隙鎖(next-key locking)策略防止幻讀。
InnoDB基于聚簇索引建立的，對(duì)主鍵查詢有很高的性能。不過它的耳機(jī)索引中必須包含主鍵列，所以如果主鍵列很大，其它的索引都會(huì)很大。因此，若表上的索引較多的話，主鍵應(yīng)當(dāng)盡可能的小。InnoDB的存儲(chǔ)格式是平臺(tái)獨(dú)立的，可以將數(shù)據(jù)和索引從Intel平臺(tái)復(fù)制到PowerPC或者Sun SPARC平臺(tái)。
作為事務(wù)型的存儲(chǔ)引擎，InnoDB通過一些機(jī)制和工具支持真正的熱備份，Oracle提供MySQL Enterprise Backup、Percona 提供的開源的XtraBackup都可以做到這一點(diǎn)。
1.5.2 MyISAM存儲(chǔ)引擎
在MySQL5.1之前的版本，MyISAM是默認(rèn)的存儲(chǔ)引擎。MyISAM提供了大量的特性，包括全文索引、壓縮、空間函數(shù)等，但不支持事務(wù)和行級(jí)鎖。
1.8 總結(jié)
MySQL擁有分層的架構(gòu)。上層是服務(wù)器層的服務(wù)和查詢執(zhí)行引擎，下層則是存儲(chǔ)引擎。雖然有很多不同歐諾個(gè)作用的插件API，但存儲(chǔ)引擎API還是最重要的。
