共計 4774 個字符，預計需要花費 12 分鐘才能閱讀完成。

自動寫代碼機器人，免費開通

這篇文章主要介紹 MySQL 架構是什么，文中介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們一定要看完！

MySQL 服務器架構、各種存儲引擎間的主要區別及區別的重要性

回顧 MySQL 歷史背景、基準測試，通過簡化細節和演示案例來討論 MySQL 的原理

正文：

MySQL 架構可在多種不同場景中應用，可嵌入到應用程序中農，支持數據倉庫、內容索引、部署軟件、高可用冗余系統、在線事務處理系統等；

MySQL 最重要的特性是他的存儲引擎架構，使得查詢處理及其他系統任務和數據存儲、提取分離；

1.1MySQL 邏輯架構

1.2 并發控制鎖粒度：

鎖策略：在鎖開銷和數據安全性間尋求平衡，每個存儲引擎可實現指定鎖策略和粒度

表鎖：table lock   最基本的 開銷最小 鎖定整表

行級鎖：row lock 最大程度支持并發   最大的鎖開銷 在存儲引擎層（以自己的方式）實現

1.3 事務

獨立工作單元，一組原子性 SQL 查詢

隔離級別：

四種，每種規定了事務中所作的修改，較低的隔離可以執行更高的并發、開銷也更低

READ UNCOMMITTED 未提交讀

事務中的修改及時沒有提交，對其他事務也是可見的；事務讀取未提交的數據：臟讀；很少使用

READ COMMITTED 提交讀

almost 庫默認隔離級別，非 MySQL；事務從開始到結束只看見已提交的事務所作的修改，本身所做的修改對其他事務不可見；不可重復讀：兩次執行同樣的查詢，結果可能不一樣（其他事務的修改）

REPEATABLE READ 可重復讀

MySQL 默認，解決了臟讀，同一事務多次讀同樣結果；幻讀：當某個事務在讀取某個范圍內的記錄時、另一個事務在該范圍內插入新的記錄，當前事務再次讀取該范圍記錄、幻行

SERIALIZABLE: 可串行化

最高，強制事務串行執行，避免幻讀問題，讀取每行數據時加鎖（可導致大量超時和鎖爭用），很少使用

死鎖

1、兩個多個事務在同一個資源上相互占用并請求鎖定對方占用的資源；

2、多個事務試圖以不同的順序鎖定資源，可能產生死鎖；

3、多個事務同時鎖定同一個資源；

鎖的行為和順序和存取引擎相關，同樣的順序執行語句，一些存儲引擎會產生死鎖一些不會；

死鎖產生的雙重原因：因為真正的數據沖突 (很難避免），因為存儲引擎的實現方式導致；

死鎖發送后，只有部分或完全回滾其中一個事務，才能打破死鎖：InnoDB 即回滾持有最少行級排他鎖的事務；

1.3.4MySQL 中的事務: 存儲引擎實現

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

自動提交 AUTOCOMMIT；

默認采用自動提交模式，如果不顯式開始一個事務，則每個查詢都被當做一個事務執行提交操作，可通過 AUTOCOMMIT 變量來啟用 =1  =ON、禁用 =0  =OFF（all 查詢都在一個事務中直到顯式 commit rollback）事務結束同時開始新的事務，修改這個變量對非事務型表沒有任何影響；

MySQL 可以通過 set transaction isolation level 設置隔離級別，新的級別在下一個事務開始時生效，配置文件設置整個庫的，也可只改變當前會話的隔離級別

set session transaction isolation level read committed;

建議：不管何時都不要顯示執行 LOCK TABLES，不管使用的是什么存儲引擎

1.4 多版本并發控制 MVCC

數據庫 MySQL、Oracle、postgresql 等都實現了 MVCC，各自實現機制不同【源】

MVCC: 每個連接到數據庫的讀、在某個瞬間看到的是數據庫的快照，寫操作在提交之前對外不可見；【源】

更新時，將舊數據標記為過時且在別處增加新版本的數據（多個版本的數據，只有一個最新），容許讀取之前的數據

特點：

1、每行數據都存在一個版本，每次數據更新時都更新該版本

2、修改時 copy 出當前版本、隨意修改，各事務間不干擾

3、保存時比較版本號，成功 commit 則覆蓋原紀錄，失敗則放棄 rollback

4、只在 REPEATABLE READ 和 READ COMMITTED 兩個隔離級別下工作

1.5MySQL 存儲引擎

mysql 將每個數據庫保存位數據目錄下的一個子目錄，創建表示，mysql 在子目錄下創建與表同名的.frm 文件保存表的定義，不同存儲引擎保存數據和索引的方式不同，但表的定義在 MySQL 服務層同一處理；

InnoDB: 默認事務型引擎、最重要、廣泛使用

處理大量短期事務；其性能和自動崩潰恢復特性、非事務型存儲的需求中也很流行

數據存儲在由 InnoDB 管理的表空間中，由一系列數據文件組成；

使用 MVCC 支持高并發，并實現了四個標準的隔離級別，默認是 REPEATABLE READ 可重復讀，通過間隙鎖 next-key locking 防止幻讀，間隙鎖使得 InnoDB 鎖定查詢設計的行還鎖定索引中的間隙防止喚影行；

間隙鎖：

當使用范圍條件并請求鎖時，InnoDB 給符合條件的已有數據記錄的索引項加鎖，對應鍵值在條件范圍內但是不存在的記錄（間隙）加鎖，間隙鎖:【源】

// 如 emp 表中有 101 條記錄，其 empid 的值分別是  1,2,...,100,101
Select * from emp where empid   100 for update;

InnoDB 對符合條件的 empid 值為 101 的記錄加鎖，也會對 empid 大于 101（這些記錄并不存在）的“間隙”加鎖；

1、上面的例子，如果不使用間隙鎖，如果其他事務插入大于 100 的記錄，本事務再次執行則幻讀，但是會造成鎖等待，在并發插入比較多時、要盡量優化業務邏輯，使用相等條件來訪問更新數據，避免使用范圍條件；

2、在使用相等條件請求給一個不存在的記錄加鎖時，也會使用間隙鎖，當我們通過參數刪除一條記錄時，如果參數在數據庫中不存在，庫會掃描索引，發現不存在，delete 語句獲得一個間隙鎖，庫向左掃描掃到第一個比給定參數小的值，向右掃描到第一個比給定參數大的值，構建一個區間，鎖住整個區間內數據；【源】

1.5.2MyIsSAM 存儲引擎

全文索引、壓縮、空間函數，不支持事務和行級鎖，崩潰后無法安全恢復

存儲：

將表存儲在兩個文件中：數據.MYD、索引文件.MYI

表可以包含動態或靜態（長度固定）行，MySQL 據表定義來決定采用何種行格式

表如是變長行，默認配置只能處理 256TB 數據（指向記錄的指針長度 6 字節），改變表指針長度，修改表的 MAX_ROWS 和 AVG_ROW_LENGTH，兩者相乘 = 表可到達的 max 大小，修改會導致重建整個表、表 all 索引；

特性：

1、對整張表加鎖，讀、共享鎖，寫、排他鎖，但在讀的同時可從表中插入新記錄：并發插入

2、修復：可手工、自動執行檢查和修復操作，CHECK TABLE mytable 檢查表錯誤，REPAIR TABLE mytable 進行修復，執行修復可能會丟失些數據，如果服務器關閉，myisamchk 命令行根據檢查和修復操作；

3、索引特性：支持全文索引，基于分詞創建的索引，支持復雜查詢

4、延遲更新索引鍵 Delayed Key Write, 如果指定了 DELAY_KEY_WRITE 選項，每次修改完，不會立即將修改的索引數據寫入磁盤，寫入到內存的鍵緩沖區，清理此區或關閉表時將對應的索引塊寫入到磁盤，提升寫性能，但是在庫或主機崩潰時造成索引損壞、需要執行修復操作

壓縮表：

表在創建并導入數據后，不再修改，比較適合，可使用 myisampack 對 MyISAM 表壓縮（打包），壓縮表不能修改（除非先解除壓縮、修改數據、再次壓縮）；減少磁盤空間占用、磁盤 IO，提升查詢性能，也支持只讀索引；

現在的硬件能力，讀取壓縮表數據時解壓的開銷不大，減少 IO 帶來的好處大得多，壓縮時表記錄獨立壓縮，讀取單行時不需要解壓整個表

性能：

設計簡單，緊密格式存儲；典型的性能問題是表鎖的問題，長期處于 locked 狀態：找表鎖

1.5.3 內建的其他存儲引擎

Archive：適合日志和數據采集類應用，針對高速插入和壓縮優化，支持行級鎖和專業緩存區，緩存寫利用 zlib 壓縮插入的行，select 掃描全表；

Blackhole：復制架構和日志審核，其服務器記錄 blackhole 表日志，可復制數據到備庫 日志；

CSV：數據交換機制，將 CSV 文件作為 MySQL 表來處理，不支持索引；

Federated：訪問其他 MySQL 服務器的代理，創建遠程 mysql 的客戶端連接將查詢傳輸到遠程服務器執行，提取發送需要的數據，默認禁用；

Memory：快速訪問不會被修改的數據，數據保存在內存、不 IO，表結構重啟后還在但數據沒了

1、查找 或 映射 表，2、緩存周期性聚合數據，3、保存數據分析中產生的中間數據

支持 hash 索引，表級鎖，查找快并發寫入性能低，不支持 BLOB/TEXT 類型的列，每行長度固定，內存浪費

Merge：myisam 變種，多個 myisam 合并的虛擬表

NDB 集群引擎：

1.5.4 第三方存儲引擎

OLTP 類:

XtraDB 基于 InnoDB 改進，性能、可測量性、操作靈活

PBXT：ACID/MVCC，引擎級別的復制、外鍵約束，較復雜架構對固態存儲 SSD 適當支持，較大值類型 BLOB 優化

TokuDB：大數據，高壓縮比，大數據量創大量索引

RethinkDB: 固態存儲

面向列的

列單獨存儲，壓縮效率高

Infobright：大數據量，數據分析、倉庫應用設計的，高度壓縮，按照塊（一組元數據）排序；塊結構準索引，不支持索引（量大索引也沒用），如查詢無法再存儲層使用面向列的模式執行，則需要在服務器層轉換成按行處理

社區存儲引擎：***

1.5.5 選擇合適的引擎

除非需要用到某些 InnoDB 不具備的特性，且無辦法可以替代，否則優先選擇 InnoDB 引擎

不要混合使用多種存儲引擎，如果需要不同的存儲引擎：

1、事務：需要事務支出，InnoDB XtraDB；不需要 主要是 select insert 那 MyISAM

2、備份：定期關閉服務器來執行備份，該因素可忽略；在線熱備份，InnoDB

3、崩潰恢復：數據量較大，MyISAM 崩后損壞概率比 InnoDB 高很多、恢復速度慢

4、持有的特性：

1.5.6 轉換表的引擎

ALTER TABLE: 最簡單

ALTER TABLE mytable ENGINE=InnoDB

此會執行很長時間，MySQL 按行將數據從原表復制到新表中，在復制期間可能會消耗掉系統 all 的 I / O 能力，同時原表上加讀鎖；會失去和原引擎相關的 all 特性

導出與導入：

mysqldump 工具將數據導出到文件，修改文件中 CREATE_TABLE 語句的存儲引擎選項，同時修改表名（同一個庫不能存在相同的表名），mysqldump 默認會自動在 CREATE_TABLE 語句前加上 DROP TABLE 語句

創建與查詢：CREATE SELECT

綜合上述兩種方法：先建新存儲引擎表，利用 INSERT……SELECT 語法導數

CREATE TABLE innodb_table LIKE myisam_table
ALTER TABLE innodb_table ENGINE=InnoDB;
INSERT INTO innodb_table SELECT * FROM myisam_table;
數據量大的話，分批處理（放事務中）

1.6MySQL 時間線 Timeline

早期 MySQL 破壞性創新，有諸多限制，且很多功能只能說是二流的，但特性支持和較低的使用成本，使受歡迎；5.x 早起引入視圖、存儲過程等，期望成為“企業級”數據庫，但不算成功，5.5 顯著改善

1.7MySQL 開發模式

遵循 GPL 開源協議，全部源代碼開發給社區，部分插件收費；

以上是“MySQL 架構是什么”這篇文章的所有內容，感謝各位的閱讀！希望分享的內容對大家有幫助，更多相關知識，歡迎關注丸趣 TV 行業資訊頻道！

向 AI 問一下細節