前言：

高效讀書，一張邏輯圖帶你讀懂、讀薄書中重點。

深入學習MySQL系列，解讀的目的是為了把書讀薄，抽出重點進行梳理、理解、運用。因大量文字很容易讓人覺得枯燥無味，為此博主花費一定精力和時間整理輸出為邏輯思維圖，以便大家學習和參考。

--------------------------------------------------------------------------------------
注：下面文字只是對邏輯思維圖的”翻譯“，節省時間，只看圖即可。

目錄

MySQL架構與歷史邏輯思維圖

MySQL邏輯架構

連接管理與安全性

優化與執行

并發控制

讀寫鎖

鎖粒度

鎖策略

事務

特性

隔離級別

死鎖

事務日志

MySQL中的事務

多版本并發控制

MySQL存儲引擎

InnoDB 存儲引擎

MyISAM 存儲引擎

MySQL 內建的其他存儲引擎

第三方存儲引擎

選擇合適的引擎

轉換表的引擎

MySQL時間線

MySQL開發模式

總結

---

MySQL架構與歷史邏輯思維圖

MySQL架構與歷史

?

MySQL邏輯架構

三層架構

第一層 連接/線程處理

連接處理、授權認證、安全認證等

第二層 MySQL核心服務

查詢解析、分析、優化、緩存以及所有內置函數等

所有跨存儲引擎的功能：存儲過程、觸發器、視圖等

第三層 存儲引擎

負責MySQL中數據的存儲和提取

服務器通過API與存儲引擎進行通信，API屏蔽了不同存儲引擎之間的差異

存儲引擎不會去解析SQL，不同存儲引擎之間也不會相互通信

連接管理與安全性

每個客戶端連接對應一個線程。服務器會負責緩存，不需要每一個新建的連接創建或者銷毀線程

認證基于用戶名、原始主機信息和密碼

優化與執行

解析查詢，創建內部數據結構（解析樹）。用戶可以請求優化解釋（explain）優化過程的各個因素

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

在解析查詢SQL之前，服務器會優先檢查查詢緩存（Query Cache）

并發控制

多個查詢如果在同一時刻修改數據，都會產生并發控制的問題

讀寫鎖

讀鎖是共享的，或者說是相互不阻塞的

寫鎖是排他的，也就是說一個寫鎖會阻塞其他的寫鎖和讀鎖

目的：確保在給定的時間里，只有一個用戶能執行寫入，并防止其他用戶讀取正在寫入的同一資源

鎖粒度

目的：提高共享資源并發性的方式，讓鎖定的對象更有選擇性

只鎖定需要修改的部分數據，而不是全部資源

只會對修改的數據片進行精確的鎖定

鎖策略

就是在鎖的開銷和數據的安全性之間尋求平衡

表鎖（talbe lock）

MySQL中最基本的鎖策略，并且是開銷最小的策略

行級鎖（row lock）

可以最大程度地支持并發處理（同時也帶來了最大的鎖開銷）

事務

概念：事務就是一組原子性的SQL查詢，或者說是一個獨立的工作單元

特性

原子性（atomicity）

原子的概念就是不可分割，你可以把它理解為組成物質的基本單位，也是我們進行數據處理操作的基本單位。

一致性（consistency）

一致性指的就是數據庫在進行事務操作后，會由原來的一致狀態，變成另一種一致的狀態。也就是說當事務提交后，或者當事務發生回滾后，數據庫的完整性約束不能被破壞。

隔離性（isolation）

它指的是每個事務都是彼此獨立的，不會受到其他事務的執行影響。也就是說一個事務在提交之前，對其他事務都是不可見的。

持久性（durability）

事務提交之后對數據的修改是持久性的，即使在系統出故障的情況下，比如系統崩潰或者存儲介質發生故障，數據的修改依然是有效的。因為當事務完成，數據庫的日志就會被更新，這時可以通過日志，讓系統恢復到最后一次成功的更新狀態。

事務的四大特性概括

在這四個特性中，原子性是基礎，隔離性是手段，一致性是約束條件，而持久性是我們的目的

隔離級別

READ UNCOMMITTED（未提交讀）

事務中的修改，即使沒提交，對其他事務也都是可見的

事務可以讀取未提交的數據，稱為：臟讀（Dirty Read）

實際應用中一般很少使用

READ COMMITTED（提交讀）

大多數數據庫系統的默認級別都是READ COMMITTED（MySQL不是）

一個事務開始時，只能“看見”已經提交的事務所做的修改

這個級別有時候也叫做：不可重復讀（nonrepeatableread），因為兩次執行同樣的查詢，可能會得到不一樣的結果

REPEATABLE READ（可重復讀）

該級別保證了在同一個事務中多次讀取同樣的記錄的結果是一致的

無法解決幻讀（Phantom Read）的問題，幻讀：指的是當某個事務在讀取某個范圍內的記錄時，另一個事務又在該范圍內插入了新的記錄，當之前的事務再次讀取該范圍的記錄時，會產生幻行（Phantom Row）

可重復讀是MySQL的默認事務隔離級別

SERIALIZABLE（可串行化）

最高的隔離級別

通過強制事務串行執行，避免了幻讀的問題

實際應用中很少用，只有當非常確保數據的一致性且可以接受沒有并發的情況下，才考慮采用該級別

死鎖

概念：指兩個或者多個事務在同一資源上相互占用，并請求鎖定對方占用的資源，從而導致惡性循環的現象

可能產生情況

當多個事務試圖以不同的順序鎖定資源時

當多個事務同時鎖定同一個資源時（當兩個事務都等待對方釋放鎖，同時又持有對方需要的鎖）

如何解決

死鎖檢測。檢測到死鎖的循環依賴，并立即返回一個錯誤

死鎖超時機制。當查詢的時間達到鎖等待超時的設定后放棄鎖請求

大多數情況下，只需要重新執行因死鎖回滾的事務即可

事務日志

目的：提高事務效率

使用事務日志，只需修改其內存，再把修改行為記錄到硬盤的事務日志中

事務日志持久化以后，內存中被修改的數據在后臺再慢慢地刷回到磁盤

MySQL中的事務

MySQL 兩種事務型的存儲引擎：InnoDB和NDB Cluster

自動提交（AUTOCOMMIT）

MySQL默認采用自動提交（AUTOCOMMIT）模式。意思就是每個查詢都被當做一個事務提交操作

在事務中混合使用存儲引擎

隱式和顯式鎖定

多版本并發控制

可以認為MVCC是行級鎖的一個變種，但是它在很多情況下避免了加鎖操作，因此開銷更低

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

InnoDB的MVCC，是通過在每行記錄后面保存兩個隱藏的列來實現的

MVCC 只在REPEATABLE READ（可重復讀）和READ COMMITTED（提交讀）兩個隔離級別下工作。其他兩個隔離級別都和MVCC不兼容

MySQL存儲引擎

InnoDB 存儲引擎

InnoDB是MySQL的默認事務型引擎，也是最重要、使用最廣泛的存儲引擎

它被設計用來處理大量的短期（short-lived）事務，短期事務大部分情況是正常提交的，很少會被回滾

InnoDB的性能和自動崩潰恢復特性，使得它在非事務型存儲的需求中也很流行

概覽

InnoDB的數據存儲在表空間（tablespace）中，表空間是由InnoDB管理的一個黑盒子，由一系列的數據文件組成

InnoDB 采用MVCC來支持高并發，并且實現了四個標準的隔離級別

InnoDB表是基于聚簇索引建立的

InnoDB內部做了很多優化，包括從磁盤讀取數據時采用的可預測性預讀，能夠自動在內存中創建hash索引加速讀操作，以及能夠加速插入操作的插入緩沖區等

InnoDB的行為是非常復雜的

InnoDB通過一些機制和工具支持真正的熱備份

MyISAM 存儲引擎

相關描述

在MySQL 5.1及之前的版本，MyISAM是默認的存儲引擎

MyISAM提供了大量的特性，包含全文索引、壓縮、空間函數等

MyISAM不支持事務和行級鎖，且崩潰后無法安全恢復

存儲

MyISAM會將表存儲在兩個文件中：數據文件和索引文件，分別以.MYD和.MYI為擴展名

MyISAM表如果是變長行，則默認配置只能處理256TB的數據

特性

加鎖與并發

MyISAM對整張表加鎖，而不是針對行

修復

MySQL可以手動或者自動執行檢查和修復操作

索引特性

即使是BLOB和TEXT等長字段，也可以基于前500個字符創建索引；也支持全文索引

延遲更新索引鍵（Delayed Key Write）

壓縮表

壓縮表不能進行修改；可以極大地減少磁盤空間占用和磁盤I/O

壓縮時表中的記錄是獨立壓縮的，所以讀取單行時不需要去解壓整個表

性能

設計簡單，數據以緊密格式存儲，所以某些場景下性能很好

MySQL 內建的其他存儲引擎

Archive 引擎

只支持INSERT和SELECT操作，在MySQL5.1前不支持索引

會緩存所有的寫并利用zlib對插入的行進行壓縮，所以比MyISAM表的磁盤I/O更少

支持行級鎖和專用的緩存區，可以實現高并發插入

適用場景

日志或者數據采集

需要更快速的INSERT操作的場景

Blackhole 引擎

沒有實現任何存儲機制

可以用于復制數據到備庫，或者簡單地記錄到日志

CSV 引擎

可以將普通的CSV文件（逗號分割）作為MySQL表來處理，但是不支持索引

Federated 引擎

是訪問其他MySQL服務器的一個代理

Memory 引擎

快速訪問數據，且數據不會被修改，重啟后丟失也沒關系的情景

比MyISAM表要快一個數量級

重啟后，結構還會保留，數據會丟失

適用場景

用于查找或者映射表，比如講郵編和地市名映射的表

用戶緩存數據

用戶保存數據分析中產生的中間數據

Merge 引擎

是MyISAM引擎的一個變種，由多個MyISAM表合并而來的虛擬表

NDB 集群引擎

作為SQL和NDB原生協議之間的接口

第三方存儲引擎

OLTP 類引擎

是基于InnoDB引擎的一個改進版本。改進點主要集中在性能、可測量性和操作靈活性方面

面向列的存儲引擎

MySQL默認是面向行的，每一行的數據都是一起存儲的，服務器的查詢也是以行為單位處理的

面向列的存儲方式，在大數據量處理時，可能效率更高，傳輸更少的數據，每一列的單獨存儲，壓縮效率也會更高

社區存儲引擎

Aria、Groonga、OQGraph等

選擇合適的引擎

除非需要用到某些InnoDB不具備的特性，并且沒有其他辦法可以替代，否則都應該優先選擇InnoDB引擎

如果應用需要不同的存儲引擎，考慮因素如下

事務

備份

崩潰恢復

特有的特性

常見應用場景

日志型應用

實時記錄請求日志

插入速度快，MyISAM或者Archive存儲引擎比較合適，開銷低，且插入速度快

對記錄的日志做分析報表

利用MySQL內置的復制方案將數據復制一份到備庫

備庫上執行耗時間和CPU的查詢，主庫用于高效的插入操作，互不影響

只讀或者大部分情況下只讀的表

建議采用InnoDB

訂單處理

InnoDB是訂單處理類應用的最佳選擇

電子公告牌和主題討論論壇

CD-ROM應用

可以考慮MyIsam表或者MyIsam壓縮表

大數據量

數據倉庫

轉換表的引擎

ALTER TABLE

ALTER TABLE mytable ENGINE=InnoDB；

導出與導入

mysqldump導出文件，修改文件中CREATE TABLE語句的存儲引擎選項

創建與查詢（CREATE和SELECT）

MySQL時間線

對于懷舊者，自行搜索

MySQL開發模式

遵循GPL開源協議

總結

擁有分層的架構

最初基于ISAM構建（后被MyISAM取代），后續添加了更多的存儲引擎和事務支持

存儲引擎 API 的架構的缺點。除了InnoDB引擎外的存儲引擎，選擇可能讓事情變得更加復雜

MySQL基于GPL協議開放全部源代碼，社區和客戶都可以獲得堅固而穩定的數據庫，變得更加可擴展和有價值

以上內容均為博主原創手碼梳理。碼字不易，但只要能提高，都是值得的。如果您覺得，這篇文章對您的基礎知識學習、鞏固、提高有幫助，歡迎點贊、分享、收藏，謝謝。 --天天water

總結

以上是生活随笔為你收集整理的高质量解读《高性能mysql》——第1章 MySQL架构与历史的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。