Mysql數據庫核心知識有哪些

這篇文章主要為大家展示了“Mysql數據庫核心知識有哪些”，內容簡而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓小編帶領大家一起研究并學習一下“Mysql數據庫核心知識有哪些”這篇文章吧。

一、Mysql邏輯架構

Mysql邏輯架構主要分三層：

第一層：負責連接處理，授權認證，安全等等

1、每個客戶端連接都會在服務器進程中擁有一個線程，服務器維護了一個線程池，因此不需要為每一個新建的連接創建或者銷毀線程;

2、當客戶端連接到Mysql服務器時，服務器對其進行認證，通過用戶名和密碼認證，也可以通過SSL證書進行認證;

3、一旦客戶端連接成功，服務器會繼續驗證客戶端是否具有執行某個特定查詢的權限。

第二層：負責編譯并優化SQL

1、這一層包括查詢解析，分析，優化，緩存以及所有的的內置函數;

2、對于SELECT語句，在解析查詢前，服務器會先檢查查詢緩存，如果能在其中找到對應的查詢結果，則無需再進行查詢解析、優化等過程，直接返回查詢結果;

3、所有跨存儲引擎的功能都在這一層實現:存儲過程，觸發器，視圖。

第三層：是存儲引擎

1、存儲引擎負責在MySQL中存儲數據、提取數據;

2、存儲引擎通過API與上層進行通信，這些API屏蔽了不同存儲引擎之間的差異，使得這些差異對上層查詢過程透明;

3、存儲引擎不會去解析SQL，不同存儲引擎之間也不會相互通信，而只是簡單地響應上層服務器的請求。

二、主從復制

主從復制原理，簡言之，就三步曲：

1、主數據庫有個binlog二進制文件，紀錄了所有增刪改Sql語句。(binlog線程)

2、從數據庫把主數據庫的binlog文件的sql語句復制過來。(io線程)

3、從數據庫的relay log重做日志文件中再執行一次這些sql語句。(Sql執行線程)

三、InnoDB文件存儲結構

從物理意義上講，InnoDB表由共享表空間文件(ibdata1)、獨占表空間文件(ibd)、表結構文件(.frm)、以及日志文件(redo文件等)組成。

四、表結構文件

在MYSQL中建立任何一張數據表，在其數據目錄對應的數據庫目錄下都有對應表的.frm文件,.frm文件是用來保存每個數據表的元數據(meta)信息，包括表結構的定義等，.frm文件跟數據庫存儲引擎無關，也就是任何存儲引擎的數據表都必須有.frm文件。

五、表空間結構

1、表空間(tablespace)

所有數據都放在表空間中。如果開啟了innodb_file_per_table選項，則InnoDB會為每張表開辟一個表空間。但是需要注意的是表空間存放的只是數據、索引和插入緩沖bitmap頁，其他數據比如undo信息，插入緩沖索引頁，系統事務信息，二次寫緩沖還是會放在原來的共享表空間內。

如果rollback后，共享表空間不會自動收縮，但是會判斷空間是否需要(比如undo空間)，如果不需要的話，會將這些空間標記為可用空間，供下次undo使用。

2、段(segment)

表空間由各個段組成，比如數據段，索引段，回滾段等。

3、區(extent)

區由連續的頁組成，在任何情況下區的大小都是1M。InnoDB存儲引擎一次從磁盤申請大概4-5個區(4-5M)。在默認情況下，頁的大小為16KB，即一個區中有大概64個連續的頁。

4、頁(page)

InnoDB磁盤管理的最小單位。B樹節點= 一個物理Page(16K)，數據按16KB切片為Page 并編號， 編號可映射到物理文件偏移(16K * N)，B+樹葉子節點前后形成雙向鏈表。Page分為幾種類型，數據頁和索引頁就是其中最為重要的兩種類型。

六、緩沖池

InnoDB存儲引擎是基于磁盤存儲的，并將其中的記錄按照頁的方式進行管理，但是由于CPU速度和磁盤速度之間的鴻溝，基于磁盤的數據庫系統通常使用緩沖池記錄來提高數據庫的的整體性能。

在數據庫中進行讀取操作，首先將從磁盤中讀到的頁放在緩沖池中，下次再讀相同的頁中時，首先判斷該頁是否在緩沖池中。若在緩沖池中，稱該頁在緩沖池中被命中，直接讀取該頁。否則，讀取磁盤上的頁。

七、重做日志

默認情況在數據庫數據文件夾下會有兩個文件，ib_logfile0/ib_logfile1, 這就是重做日志文件，記錄了對于InnoDB存儲引擎的事務日志。

每個Innodb存儲引擎至少有1個重做日志文件組，每個組至少包含2個重做日志文件(ib_logfile0,ib_logfile1)。

可以通過設置多個鏡像日志組(mirrored log groups)，將不同組放到不同磁盤，提高重做日志的高可用性。

日志組中的文件大小是一致的，以循環的方式運行。文件1寫滿時，切換到文件2，文件2寫滿時，再次切換到文件1.日志組中的文件大小是一致的，以循環的方式運行。文件1寫滿時，切換到文件2，文件2寫滿時，再次切換到文件1(從頭寫入)。

為了保證數據的安全性，事務進行中時會不斷的產生redo log，在事務提交時進行一次flush操作，保存到磁盤中, redo log是按照順序寫入的，磁盤的順序讀寫的速度遠大于隨機讀寫。當數據庫或主機失效重啟時，會根據redo log進行數據的恢復，如果redo log中有事務提交，則進行事務提交修改數據。這樣實現了事務的原子性、一致性和持久性。

對于寫入重寫日志文件的操作不是直接寫，而是先寫入一個重做日志緩沖(redo lopg buffer)中，然后按照一定的條件寫入日志文件。

當對應事務的臟頁寫入到磁盤之后，redo log的使命也就完成了，重做日志占用的空間就可以重用(被覆蓋)。

通過innodb_log_buffer_size可以配置重寫日志緩沖的的大小。

從日志緩沖寫入磁盤有兩個時間點：

1、主線程每秒都會將重做日志緩沖寫入磁盤的重做日志文件，不論事務是否已經提交;

2、另外一個是由參數innodb_flush_log_at_trx_commit控制，表示在事務提交時，處理重做日志;

參數innodb_flush_log_at_trx_commit可設的值有0、1、2。0代表當提交事務時，并不將事務的重做日志寫入磁盤上的日志文件，而是等待主線程每秒的刷新。而1和2不同的地方在于：1是在commit時將重做日志緩沖同步寫到磁盤;2是重做日志異步寫到磁盤，即不能完全保證commit時肯定會寫入重做日志文件，只是有這個動作。

八、回滾日志

除了重做記錄redo log外，當進行數據修改時還會記錄undo log，undo log用于數據的撤回操作，它記錄了修改的反向操作，比如，插入對應刪除，修改對應修改為原來的數據，通過undo log可以實現事務回滾，并且可以根據undo log回溯到某個特定的版本的數據，實現MVCC，也即非鎖定讀。

事務開始之前，將當前的版本生成undo log，undo 也會產生 redo 來保證undo log的可靠性，事務提交之后，undo log并不能立馬被刪除，而是放入待清理的鏈表，由purge線程判斷是否由其他事務在使用undo段中表的上一個事務之前的版本信息，決定是否可以清理undo log的日志空間。

默認情況下undo文件是保持在共享表空間的，也即ibdatafile文件中，當數據庫中發生一些大的事務性操作的時候，要生成大量的undo信息，全部保存在共享表空間中的。因此共享表空間可能會變的很大，默認情況下，也就是undo 日志使用共享表空間的時候，被“撐大”的共享表空間是不會也不能自動收縮的。

九、ACID

ACID是事務的四大特性。

1、原子性(Atomicity)

一個事務必須被視為一個不可分割的最小工作單元，整個事務中的所有操作要么全部提交成功，要么全部失敗回滾，對于一個事務來說，不可能只執行其中的一部分操作，這就是事務的原子性。

2、一致性(Consistency)

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

3、隔離性(Isolation)

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

4、持久性(Durability)

一旦事務提交，則其所做的修改不會永久保存到數據庫

十、事務的隔離性問題

如果不考慮事務的隔離性，會出現以下問題：

1、臟讀

一個事務在更新一條記錄，未提交前，第二個事務讀到了第一個事務更新后的記錄，那么第二個事務就讀到了臟數據，會產生對第一個未提交數據的依賴。一旦第一個事務回滾，那么第二個事務讀到的數據，將是錯誤的臟數據。

2、幻讀

一個事務按相同的查詢條件查詢之前檢索過的數據，確發現檢索出來的結果集條數變多或者減少(由其他事務插入、刪除的)，類似產生幻覺。

3、不可重復讀(虛讀)

一個事務在讀取某些數據后的一段時間后，再次讀取這個數據，發現其讀取出來的數據內容已經發生了改變，就是不可重復讀。

幻讀和不可重復讀的區別在于幻讀是數據條數發生了變化(插入、刪除)，而不可沖突讀在于數據發生了更新，前后讀取的結果不一致。

十一、事務隔離級別

臟讀、不可重讀度、幻讀，其實都是數據庫的一致性問題，必須由一定的事務隔離機制來解決，InnoDB下的事務隔離級別有以下四種：

1、讀未提交(Read uncommitted)

一個事務可以讀取到另一個事務未提交的修改。這會帶來臟讀、幻讀、不可重復讀問題。(基本沒用)

2、讀已提交(RC, Read Commit)

一個事務只能讀取另一個事務已經提交的修改。其避免了臟讀，但仍然存在不可重復讀和幻讀問題。

3、可重復讀(RR, Repeatable Read)

同一個事務中多次讀取相同的數據返回的結果是一樣的。其避免了臟讀和不可重復讀問題，但幻讀依然存在。

4、串行化(Serializable)

事務串行執行。避免了以上所有問題。MySQL 默認的級別是:Repeatable read 可重復讀，級別越高，數據越安全，但性能越低。

十二、MVCC

MVCC(Mutil-Version Concurrency Control)，多版本并發控制，是為了查詢一些正在被另一個事務更新的行，并且可以看到它們被更新之前的值。這是一個可以用來增強并發性的強大的技術，因為這樣的一來的話查詢就不用等待另一個事務釋放鎖。

MVCC的實現是通過保存數據在某個時間點的快照(redo log)來實現的。這意味著一個事務無論運行多長時間，在同一個事務里能夠看到數據一致的視圖。根據事務開始的時間不同，同時也意味著在同一個時刻不同事務看到的相同表里的數據可能是不同的。

在每一行數據中額外保存兩個隱藏的列：當前行創建時的版本號和刪除時的版本號(可能為空)。這里的版本號并不是實際的時間值，而是系統版本號。每開始新的事務，系統版本號都會自動遞增。事務開始時刻的系統版本號會作為事務的版本號，用來和查詢每行記錄的版本號進行比較。

每個事務又有自己的版本號，這樣事務內執行CRUD操作時，就通過版本號的比較來達到數據版本控制的目的。

默認的隔離級別(REPEATABLE READ)下，增刪查改變成了這樣：

SELECT：讀取創建版本小于或等于當前事務版本號，并且刪除版本為空或大于當前事務版本號的記錄。這樣可以保證在讀取之前記錄是存在的。

INSERT：將當前事務的版本號保存至行的創建版本號

UPDATE：新插入一行，并以當前事務的版本號作為新行的創建版本號，同時將原記錄行的刪除版本號設置為當前事務版本號

DELETE：將當前事務的版本號保存至行的刪除版本號

十三、InnoDB索引結構

Mysql索引用的B+樹作為數據結構;Mysql中B+Tree在經典B+Tree的基礎上進行了優化，增加了順序訪問指針。在B+Tree的每個葉子節點增加一個指向相鄰葉子節點的指針，就形成了帶有順序訪問指針的B+Tree。這樣就提高了區間訪問性能：如果要查詢key為從18到49的所有數據記錄，當找到18后，只需順著節點和指針順序遍歷就可以一次性訪問到所有數據節點，極大提到了區間查詢效率(無需返回上層父節點重復遍歷查找減少IO操作)。

MyISAM & InnoDB 都使用B+Tree索引結構。但是底層索引存儲不同，MyISAM 采用非聚簇索引，而InnoDB采用聚簇索引。

聚簇索引： 索引 和 數據文件為同一個文件。

非聚簇索引： 索引 和 數據文件分開的索引。

MyISAM索引原理：采用非聚簇索引-MyISAM myi索引文件和myd數據文件分離，索引文件僅保存數據記錄的指針地址。葉子節點data域存儲指向數據記錄的指針地址。

MyISAM索引按照B+Tree搜索，如果指定的Key存在，則取出其data域的值，然后以data域值-數據指針地址去讀取相應數據記錄。輔助索引和主索引在結構上沒有任何區別，只是主索引要求key是唯一的，而輔助索引的key可以重復。

InnoDB索引采用聚簇索引，InnoDB數據&索引文件為一個idb文件，表數據文件本身就是主索引，相鄰的索引臨近存儲。 葉節點data域保存了完整的數據記錄(數據[除主鍵id外其他列data]+主索引[索引key:表主鍵id])。 葉子節點直接存儲數據記錄，以主鍵id為key,葉子節點中直接存儲數據記錄。(底層存儲結構:** frm -表定義、 ibd: innoDB數據&索引文件)

由于InnoDB采用聚簇索引結構存儲，索引InnoDB的數據文件需要按照主鍵聚集，因此InnoDB要求表必須有主鍵(MyISAM可以沒有)。如果沒有指定mysql會自動選擇一個可以唯一表示數據記錄的列作為主鍵，如果不存在這樣的列，mysql自動為InnoDB表生成一個隱含字段(6個字節長整型)作為主鍵。 InnoDB的所有輔助索引都引用數據記錄的主鍵作為data域。

十四、InnoDB鎖類型

1、加鎖機制

樂觀鎖與悲觀鎖是兩種并發控制的思想，可用于解決丟失更新問題。

2、樂觀鎖

每次去取數據，都很樂觀，覺得不會出現并發問題。因此，訪問、處理數據每次都不上鎖。但是在更新的時候，再根據版本號或時間戳判斷是否有沖突，有則處理，無則提交事務。

3、悲觀鎖

每次去取數據，很悲觀，都覺得會被別人修改，會有并發問題。因此，訪問、處理數據前就加排他鎖。在整個數據處理過程中鎖定數據，事務提交或回滾后才釋放鎖。

4、鎖粒度

表鎖：開銷小，加鎖快;鎖定力度大，發生鎖沖突概率高，并發度最低;不會出現死鎖。

行鎖：開銷大，加鎖慢;會出現死鎖;鎖定粒度小，發生鎖沖突的概率低，并發度高。

頁鎖：開銷和加鎖速度介于表鎖和行鎖之間;會出現死鎖;鎖定粒度介于表鎖和行鎖之間，并發度一般。

5、兼容性

01、共享鎖

又稱讀鎖(S鎖)。一個事務獲取了共享鎖，其他事務可以獲取共享鎖，不能獲取排他鎖，其他事務可以進行讀操作，不能進行寫操作。SELECT … LOCK IN SHARE MODE 顯示加共享鎖。

02、排他鎖

又稱寫鎖(X鎖)。如果事務T對數據A加上排他鎖后，則其他事務不能再對A加任任何類型的封鎖。獲準排他鎖的事務既能讀數據，又能修改數據。SELECT … FOR UPDATE 顯示添加排他鎖。

6、鎖模式

記錄鎖：在行相應的索引記錄上的鎖，鎖定一個行記錄。

gap鎖：是在索引記錄間歇上的鎖,鎖定一個區間。

next-key鎖：是記錄鎖和在此索引記錄之前的gap上的鎖的結合，鎖定行記錄+區間。

意向鎖：是為了支持多種粒度鎖同時存在。

以上是“Mysql數據庫核心知識有哪些”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！