MySQL架構

Jun 23, 2017 pm 02:50 PM
mysql 架構

重溫《高效能MySQL》的第一章MySQL架構與歷史

1.1   MySQL邏輯架構

參考

 

 

圖1-1:MySQL伺服器邏輯架構圖

 

  最上層的服務並不是MySQL所獨有的,大多數基於網路的客戶端/伺服器的工具或服務都有類似的架構。例如連線處理、授權認證、安全性等等。

  第二層架構是MySQL比較有趣的部分。大多數MySQL的核心服務功能都在這一層,包括查詢解析、分析、最佳化、快取以及所有的內建函數(例如,日期、時間、數學和加密函數),所有跨儲存引擎的功能都在這一層實作:預存程序、觸發器、視圖等。

  第三層包含了儲存引擎。儲存引擎負責MySQL中資料的儲存和提取。和GNU/Linux下的各種檔案系統一樣,每個儲存引擎都有它的優點和缺點。伺服器透過API與儲存引擎通訊。這些介面屏蔽了不同儲存引擎之間的差異,使得這些差異對上層的查詢流程變得透明。儲存引擎API包含數十個底層函數,用於執行諸如「開始一個交易」或「根據主鍵提取一行記錄」等操作。但儲存引擎不會去解析SQL,不同儲存引擎之間也不會互相通信,而只是簡單地回應上層伺服器的請求。

1.2   並發控制

1.2.1  讀寫鎖定

  這兩種類型的鎖定通常稱為共享鎖定(shared lock)和排他鎖定(exclusive lock) ,也叫讀鎖(read lock)和寫鎖(write lock)。讀鎖是共享的,或者說是互相不阻塞的。多個客戶在同一時刻可以同時讀取同一個資源,而互不干擾。寫鎖則是排他的,也就是說一個寫鎖會阻塞其他的寫鎖和讀鎖。

1.2.2 鎖定粒度

  兩個最重要的鎖定策略:表鎖定與行級鎖定

表格鎖定(table lock)

#  表鎖是MySQL中最基本的鎖定策略,也是開銷最小的策略。它會鎖定整張表。一個使用者在對錶進行寫入操作(插入、刪除、更新等)前,需要先取得寫鎖,這會阻塞其他使用者對該表的所有讀寫操作。只有沒有寫鎖時,其他讀取的使用者才能獲得讀鎖,讀鎖之間是不互相阻塞的。

  在特定的場景中,表鎖也可能有良好的效能。例如,READ LOCAL表鎖支特某些類型的並發寫入操作。另外,寫鎖也比讀鎖有更高的優先權,因此一個寫鎖請求可能會被插入到讀鎖佇列的前面(寫鎖可以插入到鎖佇列中讀鎖的前面,反之讀鎖則不能插入到寫鎖的前面)。

行級鎖定( row lock)   

  行級鎖定可以最大程度地支援並發處理(同時也帶來了最大的鎖開銷)。眾所周知,在InnoDB和XtraDB,以及其他一些儲存引擎中實現了行級鎖定。行級鎖只在儲存引擎層實現,而MySQL伺服器層沒有實現。伺服器層完全不了解儲存引擎中的鎖實作。

1.3   事務

事務支援ACID原則。

原子性(atomicity)

  一個交易必須被視為一個不可分割的最小工作單元。

一致性(consistency) 

  資料庫總是從一個一致性的狀態轉換到另一個一致性的狀態。

隔離性(isolation)

  通常來說,一個事務所所做的修改在最終提交以前,對其他事務是不可見的。

持久性(durability)

  一旦交易提交,則其所做的修改就會永久保存到資料庫中。

1.3.1  隔離等級

以下簡單介紹四種隔離等級。

READ UNCOMMITTED(未提交讀取)

  在READ UNCOMMITTED級別,事務中的修改,即使沒有提交,對其他事務也都是可見的。事務可以讀取未提交的數據,這也被稱為髒讀(Dirty Read)。這個等級會導致很多問題,從效能上來說,READ UNCOMMITTED不會比其他的等級好太多,但卻缺乏其他等級的許多好處,除非真的有非常必要的理由,在實際應用中一般很少使用。

READ COMMITTED(提交讀取)

  大多數資料庫系統的預設隔離等級都是READ COMMITTED(但MySQL不是)。一個事務從開始直到提交之前,所做的任何修改對其他事務都是不可見的。這個等級有時候也叫做不可重複讀(nonrepeatable read),因為兩次執行同樣的查詢,可能會得到不一樣的結果。

REPEATABLE READ(可重複讀取)

  REPEATABLE READ解決了髒讀取的問題。此等級保證了在同一個事務中多次讀取同樣記錄的結果是一致的。但理論上,可重複讀取隔離等級還是無法解決另一個幻讀 (Phantom Read)的問題。所謂幻讀,指的是當某個事務在讀取某個範圍內的記錄時,另外一個事務又在該範圍內插入了新的記錄,當之前的事務再次讀取該範圍的記錄時,會產生幻行(Phantom Row)。 InnoDB和XtraDB儲存引擎透過多版本並發控制(MVCC,Multiversion Concurrency Control)解決了幻讀的問題。

  可重複讀取是MySQL的預設交易隔離等級。

SERIALIZABLE(可串列化​​)

  SERIALIZABLE是最高的隔離等級。它透過強制事務串列執行,避免了前面說的幻讀的問題。簡單來說,SERIALIZABLE會在謨取的每一行資料上都加鎖,所以可能會導致大量的逾時和鎖爭用的問題。實際應用中也很少用到這個隔離級別,只有在非常需要確保資料的一致性而且可以接受沒有並發的情況下,才考慮採用該級別。

 

1.3.2  死鎖

  死鎖是指兩個或多個事務在同一資源上相互佔用,並請求鎖定對方佔用的資源,從而導致惡性循環的現象。當多個事務試圖以不同的順序鎖定資源時,就可能會產生死鎖。多個事務同時鎖定同一個資源時,也會產生死鎖。

  為了解決這個問題,資料庫系統實作了各種死鎖偵測和死鎖逾時機制。越複雜的系統,例如InnoDB儲存引擎,越能偵測到死鎖的循環依賴,並立即回傳一個錯誤。這種解決方式很有效,否則死鎖會導致出現非常慢的查詢。還有一種解決方式,就是當查詢的時間達到鎖等待超時的設定後放棄鎖定請求,這種方式通常來說不太好。 InnoDB目前處理死鎖的方法是,將持有最少行級排他鎖的事務進行回滾(這是相對比較簡單的死鎖回滾演算法)。

  鎖的行為和順序是和儲存引擎相關的。以同樣的順序執行語句,有些儲存引擎會產生死鎖,有些則不會。死鎖的產生有雙重原因:有些是因為真正的資料衝突,這種情況通常很難避免,但有些則完全是由於儲存引擎的實現方式導致的。

1.3.3  交易日誌

  使用交易日誌,儲存引擎在修改表的資料時只需要修改其記憶體拷貝,再把該修改行為記錄到持久在硬碟上的交易日誌中,而不用每次都將修改的資料本身持久到磁碟。交易日誌採用的是追加的方式。交易日誌持久以後,記憶體中被修改的資料在後台可以慢慢地刷回到磁碟。目前大多數儲存引擎都是這樣實現的,我們通常稱為預寫式日誌(Write-Ahead Logging),而修改資料需要寫兩次磁碟。

  如果資料的修改已經記錄到交易日誌並且持久化,但資料本身還沒有寫回磁碟,此時系統崩潰,儲存引擎在重新啟動時能夠自動恢復這部分修改的資料。具體的恢復方式則視儲存引擎而定。

1.3.4  MySQL中的交易

1.4   多版本並發控制

  MVCC的實現,是透過保存資料在某個時間點的快照來實現的。也就是說,不管需要執行多長時間,每個事務看到的資料都是一致的。根據事務開始的時間不同,每個事務對同一張表,同一時刻看到的資料可能是不一樣的。下面我們透過InnoDB的簡化版行為來說明MVCC是如何運作的。

  InnoDB的MVCC,是透過在每行記錄後面保存兩個隱藏的列來實現的。這兩個列,一個保存了行的建立時間,一個保存行的過期時間(或刪除時間)。當然儲存的並不是實際的時間值,而是系統版本號(system version number)。每開始一個新的事務,系統版本號就會自動遞增。事務開始時刻的系統版本號碼會作為事務的版本號,用來和查詢到的每行記錄的版本號進行比較。以下來看看在REPEATABLE READ隔離等級下,MVCC具體是如何操作的。

SELECT

  InnoDB會依照下列兩個條件檢查每行記錄:

      a. InnoDB只查找版本早於目前事務版本的資料行(也就是,行的系統版本號小於或等於事務的系統版本號),這樣可以確保事務讀取的行,要么是在事務開始前已經存在的,要嘛是事務自身插入或修改過的。

      b.行的刪除版本要么未定義,要么大於目前事務版本號。這可以確保事務讀取到的行,在事務開始之前未被刪除。

      只有符合上述兩個條件的記錄,才能傳回作為查詢結果。

INSERT

        InnoDB為新插入的每一行儲存目前系統版本號碼作為行版本號。

DELETE

      InnoDB為刪除的每一行儲存目前系統版本號碼作為行刪除識別。

UPDATE

      InnoDB為插入一行新記錄,保存目前系統版本號作為行版本號,同時保存當前系統版本號到原來的行作為行刪除標識。

  保存這兩個額外系統版本號,使大多數讀取操作都可以不用加鎖。這樣設計使得讀取資料操作很簡單,效能很好,也能保證只會讀取到符合標準的行。不足之處是每行記錄都需要額外的儲存空間,需要做更多的行檢查工作,以及一些額外的維護工作。

  MVCC只在REPEATABLE READ和READ COMMITTED兩個隔離等級下運作。其他兩個隔離等級都和MVCC不相容於註4,因為READ UNCOMMITTED總是讀取最新的資料行,而不是符合目前交易版本的資料行。而SERIALIZABLE則會對所有讀取的行都加鎖。

1.5   MySQL的儲存引擎

  在檔案系統中,MySQL將每個資料庫(也可以稱為schema)儲存為資料目錄下的子目錄。建立表格時,MySQL會在資料庫子目錄下建立一個和表格同名的.frm檔案保存表的定義。例如建立一個名為MyTable的表,MySQL會在MyTable.frm檔案中儲存該表的定義。因為MySQL使用檔案系統的目錄和檔案來保存資料庫和表格的定義,大小寫敏感度和具體的平台密切相關。在Windows中,大小寫是不敏感的;而在類別Unix中則是敏感的。不同的儲存引擎保存資料和索引的方式是不同的,但表的定義則是在MySQL服務層統一處理的。

  可以使用SHOW TABLE STATUS指令(在MySQL 5.0以後的版本中,也可以查詢INFORMATION SCHEMA中對應的表)顯示表格的相關資訊。例如,對於mysql資料庫中的user表:

mysql> SHOW TABLE STATUS LIKE 'user' \G

          Name: user

#  Row_format: Dynamic

           Rows :  6

  Avg_row_length: 59

   #     Index length : 2048

       Data_free: 0   

  Auto_increment: NULL

##     Create_time: 2002-

##     Create_time: 2002-

##     Create_time: 2002-

##     Create_time: 2002-01024 18 01- 24  21: 56 : 29

      Check_time: NULL

        Collat​​ion : ut f8_bin# 

  ##          Comment: Users and global privileges

1 row in set (o.oo sec)

 

榆出的結果表明,這是一個MyISAM表。輸出中還有很多其他資訊以及統計資料。下面簡單介紹一下每一行的含義。

Name

表名。

Engine表的儲存引擎類型。在舊版本中,該列的名字叫Type,而不是Engine。 Row- format#行的格式。對於MyISAM表,可選的值為Dynamic、Fixed或Comp ressed。 Dynamic的行長度是可變的,一般包含可變長度的字段,如VARCHAR或BLOB。 Fixed的行長度則是固定的,只包含固定長度的列,如CHAR和INTEGER。 Compressed的行則只存在於壓縮表中。 Rows#表中的行數。對於MyISAM和其他一些儲存引擎,該值是精確的,但對於InnoDB,該值是估計值。 Avg_ row_length

平均每行包含的位元組數。

Data_length

#表格資料的大小(以位元組為單位)。

Max- data_length

#表格資料的最大容量,該值和儲存引擎有關。

Index_length

#索引的大小(以位元組為單位)。

Data_free

#對於MyISAM表,表示已指派但目前沒有使用的空間。這部分空間包括了先前刪除的行,以及後續可以被INSERT利用的空間。

Auto_increment

#下一個AUTO INCREMENT的值。

Create_time

#表的建立時間。

Update_time

#表格資料的最後修改時間。

Check_ time

#使用CKECK TABLE指令或myisamchk工具最後一次檢查表的時間。

Collat​​ion

表的預設字元集和字元列排序規則。

Checksum

#如果啟用,則儲存的是整個資料表的即時校驗和。

Create_options

#刨建表時指定的其他選項。

Comment

#該欄位包含了一些其他的額外資訊。對於MyISAM表,儲存的是表在建立時所帶的註解。對於InnoDB表,則保存的是InnoDB表空間的剩餘空間資訊。如果是視圖,則該列包含「VIEW」的文字字樣。

 

1.6   MySQL時間軸

1.7   MySQL的發展模式

 

參考:《高效能MySQL》 

以上是MySQL架構的詳細內容。更多資訊請關注PHP中文網其他相關文章!

本網站聲明
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn

熱AI工具

Undresser.AI Undress

Undresser.AI Undress

人工智慧驅動的應用程序,用於創建逼真的裸體照片

AI Clothes Remover

AI Clothes Remover

用於從照片中去除衣服的線上人工智慧工具。

Undress AI Tool

Undress AI Tool

免費脫衣圖片

Clothoff.io

Clothoff.io

AI脫衣器

Video Face Swap

Video Face Swap

使用我們完全免費的人工智慧換臉工具,輕鬆在任何影片中換臉!

熱門文章

<🎜>:泡泡膠模擬器無窮大 - 如何獲取和使用皇家鑰匙
3 週前 By 尊渡假赌尊渡假赌尊渡假赌
北端:融合系統,解釋
3 週前 By 尊渡假赌尊渡假赌尊渡假赌

熱工具

記事本++7.3.1

記事本++7.3.1

好用且免費的程式碼編輯器

SublimeText3漢化版

SublimeText3漢化版

中文版,非常好用

禪工作室 13.0.1

禪工作室 13.0.1

強大的PHP整合開發環境

Dreamweaver CS6

Dreamweaver CS6

視覺化網頁開發工具

SublimeText3 Mac版

SublimeText3 Mac版

神級程式碼編輯軟體(SublimeText3)

熱門話題

Java教學
1664
14
CakePHP 教程
1423
52
Laravel 教程
1318
25
PHP教程
1269
29
C# 教程
1248
24
laravel入門實例 laravel入門實例 Apr 18, 2025 pm 12:45 PM

Laravel 是一款 PHP 框架,用於輕鬆構建 Web 應用程序。它提供一系列強大的功能,包括:安裝: 使用 Composer 全局安裝 Laravel CLI,並在項目目錄中創建應用程序。路由: 在 routes/web.php 中定義 URL 和處理函數之間的關係。視圖: 在 resources/views 中創建視圖以呈現應用程序的界面。數據庫集成: 提供與 MySQL 等數據庫的開箱即用集成,並使用遷移來創建和修改表。模型和控制器: 模型表示數據庫實體,控制器處理 HTTP 請求。

Linux體系結構:揭示5個基本組件 Linux體系結構:揭示5個基本組件 Apr 20, 2025 am 12:04 AM

Linux系統的五個基本組件是:1.內核,2.系統庫,3.系統實用程序,4.圖形用戶界面,5.應用程序。內核管理硬件資源,系統庫提供預編譯函數,系統實用程序用於系統管理,GUI提供可視化交互,應用程序利用這些組件實現功能。

MySQL和PhpMyAdmin:核心功能和功能 MySQL和PhpMyAdmin:核心功能和功能 Apr 22, 2025 am 12:12 AM

MySQL和phpMyAdmin是強大的數據庫管理工具。 1)MySQL用於創建數據庫和表、執行DML和SQL查詢。 2)phpMyAdmin提供直觀界面進行數據庫管理、表結構管理、數據操作和用戶權限管理。

MySQL與其他編程語言:一種比較 MySQL與其他編程語言:一種比較 Apr 19, 2025 am 12:22 AM

MySQL与其他编程语言相比,主要用于存储和管理数据,而其他语言如Python、Java、C 则用于逻辑处理和应用开发。MySQL以其高性能、可扩展性和跨平台支持著称,适合数据管理需求,而其他语言在各自领域如数据分析、企业应用和系统编程中各有优势。

解決數據庫連接問題:使用minii/db庫的實際案例 解決數據庫連接問題:使用minii/db庫的實際案例 Apr 18, 2025 am 07:09 AM

在開發一個小型應用時,我遇到了一個棘手的問題:需要快速集成一個輕量級的數據庫操作庫。嘗試了多個庫後,我發現它們要么功能過多,要么兼容性不佳。最終,我找到了minii/db,這是一個基於Yii2的簡化版本,完美地解決了我的問題。

laravel框架安裝方法 laravel框架安裝方法 Apr 18, 2025 pm 12:54 PM

文章摘要:本文提供了詳細分步說明,指導讀者如何輕鬆安裝 Laravel 框架。 Laravel 是一個功能強大的 PHP 框架,它 упростил 和加快了 web 應用程序的開發過程。本教程涵蓋了從系統要求到配置數據庫和設置路由等各個方面的安裝過程。通過遵循這些步驟,讀者可以快速高效地為他們的 Laravel 項目打下堅實的基礎。

初學者的MySQL:開始數據庫管理 初學者的MySQL:開始數據庫管理 Apr 18, 2025 am 12:10 AM

MySQL的基本操作包括創建數據庫、表格,及使用SQL進行數據的CRUD操作。 1.創建數據庫:CREATEDATABASEmy_first_db;2.創建表格:CREATETABLEbooks(idINTAUTO_INCREMENTPRIMARYKEY,titleVARCHAR(100)NOTNULL,authorVARCHAR(100)NOTNULL,published_yearINT);3.插入數據:INSERTINTObooks(title,author,published_year)VA

解決MySQL模式問題:TheliaMySQLModesChecker模塊的使用體驗 解決MySQL模式問題:TheliaMySQLModesChecker模塊的使用體驗 Apr 18, 2025 am 08:42 AM

在使用Thelia開發電商網站時,我遇到了一個棘手的問題:MySQL模式設置不當,導致某些功能無法正常運行。經過一番探索,我找到了一個名為TheliaMySQLModesChecker的模塊,它能夠自動修復Thelia所需的MySQL模式,徹底解決了我的困擾。

See all articles