MySQL 工作、底層原理,看這一篇就夠了!

2020-12-15 計算機java編程

mysql原理圖各個組件說明:

1. connectors與其他程式語言中的sql 語句進行交互,如php、java等。

2. Management Serveices & Utilities系統管理和控制工具

3. Connection Pool (連接池)管理緩衝用戶連接,線程處理等需要緩存的需求

4. SQL Interface (SQL接口)接受用戶的SQL命令,並且返回用戶需要查詢的結果。比如select from就是調用SQL Interface

5. Parser (解析器)SQL命令傳遞到解析器的時候會被解析器驗證和解析。

主要功能:

a . 將SQL語句分解成數據結構,並將這個結構傳遞到後續步驟,後面SQL語句的傳遞和處理就是基於這個結構的

b. 如果在分解構成中遇到錯誤,那麼就說明這個sql語句是不合理的,語句將不會繼續執行下去

6. Optimizer (查詢優化器)

SQL語句在查詢之前會使用查詢優化器對查詢進行優化(產生多種執行計劃,最終資料庫會選擇最優化的方案去執行,儘快返會結果) 他使用的是「選取-投影-聯接」策略進行查詢。

用一個例子就可以理解:select uid,name from user where gender = 1;

這個select 查詢先根據where 語句進行選取,而不是先將表全部查詢出來以後再進行gender過濾

這個select查詢先根據uid和name進行屬性投影,而不是將屬性全部取出以後再進行過濾

將這兩個查詢條件聯接起來生成最終查詢結果.

7. Cache和Buffer (查詢緩存)

如果查詢緩存有命中的查詢結果,查詢語句就可以直接去查詢緩存中取數據。

這個緩存機制是由一系列小緩存組成的。比如表緩存,記錄緩存,key緩存,權限緩存等

8.Engine (存儲引擎)

存儲引擎是MySql中具體的與文件打交道的子系統。也是Mysql最具有特色的一個地方。

Mysql的存儲引擎是插件式的。它根據MySql AB公司提供的文件訪問層的一個抽象接口來定製一種文件訪問機制(這種訪問機制就叫存儲引擎)

SQL 語句執行過程

資料庫通常不會被直接使用,而是由其他程式語言通過SQL語句調用mysql,由mysql處理並返回執行結果。那麼Mysql接受到SQL語句後,又是如何處理?

首先程序的請求會通過mysql的connectors與其進行交互,請求到處後,會暫時存放在連接池(connection pool)中並由處理器(Management Serveices & Utilities)管理。當該請求從等待隊列進入到處理隊列,管理器會將該請求丟給SQL接口(SQL Interface)。SQL接口接收到請求後,它會將請求進行hash處理並與緩存中的結果進行對比,如果完全匹配則通過緩存直接返回處理結果;否則,需要完整的走一趟流程:

(1)由SQL接口丟給後面的解釋器(Parser),解釋器會判斷SQL語句正確與否,若正確則將其轉化為數據結構。

(2)解釋器處理完,便來到後面的優化器(Optimizer),它會產生多種執行計劃,最終資料庫會選擇最優化的方案去執行,儘快返會結果。

(3)確定最優執行計劃後,SQL語句此時便可以交由存儲引擎(Engine)處理,存儲引擎將會到後端的存儲設備中取得相應的數據,並原路返回給程序。

注意點

(1)如何緩存查詢數據

存儲引擎處理完數據,並將其返回給程序的同時,它還會將一份數據保留在緩存中,以便更快速的處理下一次相同的請求。具體情況是,mysql會將查詢的語句、執行結果等進行hash,並保留在cache中,等待下次查詢。

(2)buffer與cache的區別

從mysql原理圖可以看到,緩存那裡實際上有buffer和cache兩個,那它們之間的區別:簡單的說就是,buffer是寫緩存,cache是讀緩存。

(3)如何判斷緩存中是否已緩存需要的數據

這裡可能有一個誤區,覺得處理SQL語句的時候,為了判斷是否已緩存查詢結果,會將整個流程走一遍,取得執行結果後再與需要的進行對比,看看是否命中,並以此說,既然不管緩存中有沒有緩存到查詢內容,都要整個流程走一遍,那緩存的優勢在哪?

其實並不是這樣,在第一次查詢後,mysql便將查詢語句以及查詢結果進行hash處理並保留在緩存中,SQL查詢到達之後,對其進行同樣的hash處理後,將兩個hash值進行對照,如果一樣,則命中,從緩存中返回查詢結果;否則,需要整個流程走一遍。

當資料庫中有多個操作需要修改同一數據時,不可避免的會產生數據的髒讀。這時就需要資料庫具有良好的並發控制能力,這一切在MySQL中都是由伺服器和存儲引擎來實現的。

解決並發問題最有效的方案是引入了鎖的機制,鎖在功能上分為共享鎖(shared lock)和排它鎖(exclusive lock)即通常說的讀鎖和寫鎖。當一個select語句在執行時可以施加讀鎖,這樣就可以允許其它的select操作進行,因為在這個過程中數據信息是不會被改變的這樣就能夠提高資料庫的運行效率。當需要對數據更新時,就需要施加寫鎖了,不在允許其它的操作進行,以免產生數據的髒讀和幻讀。鎖同樣有粒度大小,有表級鎖(table lock)和行級鎖(row lock),分別在數據操作的過程中完成行的鎖定和表的鎖定。這些根據不同的存儲引擎所具有的特性也是不一樣的。

MySQL大多數事務型的存儲引擎都不是簡單的行級鎖,基於性能的考慮,他們一般都同時實現了多版本並發控制(MVCC)。這一方案也被Oracle等主流的關係資料庫採用。它是通過保存數據中某個時間點的快照來實現的,這樣就保證了每個事務看到的數據都是一致的。詳細的實現原理可以參考《高性能MySQL》第三版。

4.事務

1.簡單的說事務就是一組原子性的SQL語句。可以將這組語句理解成一個工作單元,要麼全部執行要麼都不執行。在MySQL中可以使用如下命令操作事務:

start transaction;

select …

update …

insert …

commit;

注意:默認MySQL中自動提交是開啟的:

2.事務具有ACID的特性:

原子性(atomicity):事務中的所有操作要麼全部提交成功,要麼全部失敗回滾。

一致性(consistency):資料庫總是從一個一致性狀態轉換到另一個一致性狀態。

隔離性(isolation):一個事務所做的修改在提交之前對其它事務是不可見的。

持久性(durability):一旦事務提交,其所做的修改便會永久保存在資料庫中。

3.事務的隔離級別:在SQL標準中定義了四種隔離級別:

READ UNCOMMITTED(讀未提交):事務中的修改即使未提交也是對其它事務可見

READ COMMITTED(讀提交):事務提交後所做的修改才會被另一個事務看見,可能產生一個事務中兩次查詢的結果不同。

REPEATABLE READ(可重讀):只有當前事務提交才能看見另一個事務的修改結果。解決了一個事務中兩次查詢的結果不同的問題。

SERIALIZABLE(串行化):只有一個事務提交之後才會執行另一個事務。

4.MySQL中可以利用如下語句查詢並臨時修改隔離級別:

5.死鎖:兩個或多個事務在同一資源上相互佔用並請求鎖定對方佔用的資源,從而導致惡性循環的現象。MySQL的部分存儲引擎能夠檢測到死鎖的循環依賴並產生相應的錯誤。InnoDB引擎解決死鎖的方案是將持有最少排它鎖的事務進行回滾。

5.MySQL存儲引擎及應用方案

1.MySQL採用插件式的存儲引擎架構,可以根據不同的需求為不同的表設置不同的存儲引擎。可以通過如下命令顯示資料庫中表的狀態信息,以user表為例,顯示如下:

Name:顯示的是表名Engine:顯示存儲引擎,該表存儲引擎為MyISAMRow_format:顯示行格式,對於MyISAM有Dynamic、Fixed和Compressed三種。非別表示表中有可變的數據類型,表中數據類型為固定的,以及表是壓縮表的環境。Rows:顯示錶中行數Avg_row_length:平均行長度(字節)Data_length:數據長度(字節)Max_data_length:最大存儲數據長度(字節)Data_free:已分配但未使用的空間,包括刪除數據空餘出來的空間Auto_increment:下一個插入行自動增長欄位的值Create_time:表的創建時間Update_time:表數據的最後修改時間Collation:表的默認字符集及排序規則Checksum:如果啟用,表示整個表的實時校驗和Create_options:創建表示的一些其它選項Comment:額外的一些注釋信息,根據存儲引擎的不同表示的內容也不脛相同。2.存儲引擎介紹:

InnoDB引擎:

1.將數據存儲在表空間中,表空間由一系列的數據文件組成,由InnoDB管理;

2.支持每個表的數據和索引存放在單獨文件中(innodb_file_per_table);

3.支持事務,採用MVCC來控制並發,並實現標準的4個事務隔離級別,支持外鍵;

4.索引基於聚簇索引建立,對於主鍵查詢有較高性能;

5.數據文件的平臺無關性,支持數據在不同的架構平臺移植;

6.能夠通過一些工具支持真正的熱備。如XtraBackup等;

7.內部進行自身優化如採取可預測性預讀,能夠自動在內存中創建hash索引等。

MyISAM引擎:

1.MySQL5.1中默認,不支持事務和行級鎖;

2.提供大量特性如全文索引、空間函數、壓縮、延遲更新等;

3.資料庫故障後,安全恢復性差;

4.對於只讀數據可以忍受故障恢復,MyISAM依然非常適用;

5.日誌伺服器的場景也比較適用,只需插入和數據讀取操作;

6.不支持單表一個文件,會將所有的數據和索引內容分別存在兩個文件中;

7.MyISAM對整張表加鎖而不是對行,所以不適用寫操作比較多的場景;

8.支持索引緩存不支持數據緩存。

Archive引擎:

1.只支持insert和select操作;

2.緩存所有的寫數據並進行壓縮存儲,支持行級鎖但不支持事務;

3.適合高速插入和數據壓縮,減少IO操作,適用於日誌記錄和歸檔伺服器。

Blackhole引擎:

1.沒有實現任何存儲機制,會將插入的數據進行丟棄,但會存儲二進位日誌;

2.會在一些特殊需要的複製架構的環境中使用。

CSV引擎:

1.可以打開CSV文件存儲的數據,可以將存儲的數據導出,並利用excel打開;

2.可以作為一種數據交換的機制,同樣經常使用。

Memory引擎:

1.將數據在內存中緩存,不消耗IO;

2.存儲數據速度較快但不會被保留,一般作為臨時表的存儲被使用。

Federated引擎:

能夠訪問遠程伺服器上的數據的存儲引擎。能夠建立一個連接連到遠程伺服器。

Mrg_MyISAM引擎:

將多個MYISAM表合併為一個。本身並不存儲數據,數據存在MyISAM表中間。

NDB集群引擎:

MySQL Cluster專用。

3.第三方存儲引擎:

1.OLTP類:

XtraDB:InnoDB的改進版本。

PBXT:類似InnoDB,但提供引擎級別的複製和外鍵約束,適當支持SSD存儲。

TokuDB(開源):支持分形樹索引結構,支持海量數據的分析。

2.列式存儲引擎:MySQL默認是面向行的存儲

Infobright: 支持數十TB的數據量,為數據分析和數據倉庫設計的。數據高度壓縮。

InfiniDB:可以在一組集群間做分布式查詢,有商業版但沒有典型應用案例。

3.社區存儲引擎:

Aria:解決MyISAM崩潰安全恢復問題,並能夠進行數據緩存。

Groona: 全文索引引擎。

QQGraph: 由Open query研發支持圖操作,比如查找兩點間最短距離。

SphinxSE: 該引擎為Sphinx全文索引搜索伺服器提供SQL接口。

Spider: 支持sharding並能夠基於分片實現並列查詢。

VPForMySQL: 支持垂直分區。

4.存儲引擎選取參考因素

1.是否有事務需求

如果需要事務支持最好選擇InnoDB或者XtraDB,如果主要是select和insert操作MyISAM比較合適,一般使用日誌型的應用。

2.備份操作需求

如果能夠關閉伺服器進行備份,那麼該因素可以忽略,如果需要在線進行熱備份,則InnoDB引擎是一個不錯的選擇。

3.故障恢復需求

在對恢復要求比較好的場景中推薦使用InnoDB,因為MyISAM數據損壞概率比較大而且恢復速度比較慢。

4.性能上的需求

有些業務需求只有某些特定的存儲引擎才能夠滿足,如地理空間索引也只有MyISAM引擎支持。所以在應用架構需求環境中也需要管理員折衷考慮,當然從各方面比較而言,InnoDB引擎還是默認應該被推薦使用的。

5.表引擎轉換方法

1.直接修改

2.備份修改

利用mysqldump備份工具將數據導出,修改create table語句中的存儲引擎選項。注意修改的同時修改表名。

3.創建插入

相關焦點

  • 「看這篇就夠了」Mysql join條件是要寫在on裡還是在where裡?
    select * from a left join b on(a.f1=b.f1) where (a.f2=b.f2)語句執行是:因為where條件中b.f2為null值,且mysql優化器會認為這sql具有優化空間。
  • Mysql為什麼添加索引可以提高查詢速度,看完這篇就夠了
    這篇文章我會分為以下部分進行講解,如果你懂了,那麼請繞行,別浪費你寶貴時間!只有光頭才可以變強,如果你要繼續看,請保持空杯心態!為什麼添加索引會提高查詢速度總結。找到id=8的只需要這幾步最後總結一點:如果沒有索引我們查詢數據是需要遍歷雙向鍊表來定位對應的page,現在通過索引創建的「目錄」就可以很快定位對應頁上了!其實底層實現的結構就是B+樹,B+樹作為樹的一種實現能夠讓我們很快查找出對應內容。
  • 金字塔原理-看這一篇就夠了~
    金字塔原理》,這本書主要幫我們解決兩大問題:思維混亂、邏輯不清,通過學習金字塔原理,加以練習,你可以做到想清楚、說明白。產品經理需要擁有清晰的邏輯思維和良好的寫作能力,每每要問該如何提升這些能力時,估計就會有人推薦你看《金字塔原理》,這本書主要幫我們解決兩大問題
  • 零散的MySQL基礎總是記不住?看這一篇就夠了!
    mysql> select * from c;++--++| CNO | CNAME | CTEACHER |++--++|   1 | 數學  | liming   ||   2 | 語文  | liming   ||   3 | 歷史  | xueyou   ||   4
  • MySQL底層存儲結構
    例如在我的MySQL的安裝目錄下面有一個名稱為feng的資料庫,該資料庫下的表空間如下所示:root@test:/var/lib/mysql/feng# pwd/var/lib/mysql/feng ->這是我的資料庫目錄,數據名稱為:fengroot@test:/var/lib/mysql/feng# ls -lstrtotal 14644 -rw-r 1 mysql mysql
  • 面試被問:JDBC底層是如何連接資料庫的?|sql|mysql|數據源|java|...
    背景  前兩天一個小夥伴面試的時候,被問JDBC底層是如何連接資料庫的?  他頓時一臉懵逼,因為大部分人只知道JDBC的幾個步驟,至於底層到底是怎麼連接資料庫的,還真不知道。  由於小夥伴是面試高級開發,問這種問題倒也不能說面試官過分,如果是初級或者中級,那問著問題就確實有些過分了。
  • MySQL優化原理分析及優化方案總結
    在我們的記憶儲備裡也早已記住了這些關鍵詞:避免使用SELECT*、避免使用NULL值的判斷、根據需求適當的建立索引、優化MySQL參數.但是你對於這些優化技巧是否真正的掌握了及其相應的工作原理是否吃透了呢?在我們的實際開發過程中你能充分應用到嗎?我覺得還有待考察。所以,本文將詳細介紹MySQL優化技巧以及其相應的技術原理,希望大家看完以後,能更清楚直接的了解這些優化方案,並應用到我們的工作崗位中。
  • MySQL查詢這一篇就夠了
    連接查詢當查詢結果的列來源於多張表時,需要將多張表連接成一個大的數據集,再選擇合適的列返回mysql支持三種類型的連接查詢,分別為:語法select * from 表1 inner或left或right join 表2 on 表1.列 = 表2.列例1:使用內連接查詢班級表與學生表select * from students
  • 來複習一波,HashMap底層實現原理解析
    答案是可以滴,那就是哈希表可以滿足,接下來我們一起複習HashMap中的put()和get()方法實現原理。HashMap集合的key,會先後調用兩個方法,hashCode and equals方法,這這兩個方法都需要重寫。4、為什麼放在hashMap集合key部分的元素需要重寫equals方法?
  • MySQL與容器
    在這一篇裡,簡單地為大家介紹一下MySQL在容器上的使用。既然說到了容器,首先介紹一下關於容器的相關內容。什麼是容器?讓我們看一下官網上怎麼說,https://www.docker.com/resources/what-container「A container is a standard unit of software that packages up code and all its dependencies so the application runs quickly
  • MySQL那些與日期和時間相關的函數
    究其原因是這3個函數有略微區別:  CURRENT_TIMESTAMP是NOW的同義詞,也就是說兩者是相同的。  SYSDATE函數返回的是執行到當前函數時的時間,而NOW返回的是執行SQL語句時的時間。  因此在上面的例子中,兩次執行SYSDATE函數返回不同的時間是因為第二次調用執行該函數時等待了前面SLEEP函數2秒。
  • 關於兒童安全座椅,看這一篇就夠了
    關於兒童安全座椅,看這一篇就夠了關於兒童安全座椅,看這一篇就夠了關於兒童安全座椅,看這一篇就夠了關於兒童安全座椅,看這一篇就夠了關於兒童安全座椅,看這一篇就夠了
  • 使用visual studio 對mysql進行源碼級調試
    講故事上一篇說了mysql的架構圖,很多同學反饋說不過癮,畢竟還是聽我講故事,那這篇就來說一說怎麼利用visual studio 對 mysql進行源碼級調試,畢竟源碼面前,不談隱私,聖人面前,皆為螻蟻。二:工具合集mysql是C++寫的,要想在windows上編譯,還需要下載幾個必備小工具。
  • 一篇搞懂ElasticSearch(附學習腦圖)
    既然你點進來了,說明你了解過ES或者是對ES感興趣,這一篇目的在於掃盲,主要以概念理解為主,可能會比較枯燥,但是天將降大任於斯人也,必先...這篇我以ElasticSearch是什麼、底層原理、特點和應用場景三部分來讓大家入門ElasticSearch文章末尾白嫖es學習腦圖,要個關注不過分吧?
  • 立式攪拌器安裝教程看這一篇就夠了
    立式攪拌器安裝教程看這一篇就夠了   中藍水處理成套設備(南京)有限公司,立式攪拌器,產品齊全,質量可靠,廣泛應用,歡迎來電諮詢選購!不人員進入溼井進行檢查或維護;該系統採用專用底座固定在水池底部與管連接水池頂部安裝支撐塊兩者通過導杆連接:    立式攪拌器安裝教程看這一篇就夠了特殊提示潛水攪拌機必須完全浸沒在易燃易爆腐蝕性和高溫環境下工作—型潛水排泵廣泛應用於市政工程工廠商業醫院賓館住宅區等有固體顆粒和長纖維的水廢水雨水排放供水和農田灌溉南京環保設備內回流泥泵產品介紹型泥回流泵是在潛水攪拌機生產技術基礎上發的產品
  • MySQL慢查詢記錄原理和內容解析
    作者:高鵬(網名八怪),《深入理解MySQL主從原理32講》系列文的作者。
  • 從底層原理深度剖析volatile關鍵字,徹底徵服面試官
    本篇文章從底層原理層面深度剖析volatile關鍵字是如何實現內存可見性的,同時引入了Java內存模型、指令重排序以及內存屏障等知識點作為原理分析的知識支撐。閱讀本文之前,推薦大家先閱讀作者之前的一篇關於happens-before的文章,這樣更有助於大家對volatile關鍵字底層原理的理解。
  • 關於GC原理和性能調優,看這一篇就夠了!
    前言 本文介紹 GC 基礎原理和理論,GC 調優方法思路和方法,基於 Hotspot jdk1.8,學習之後你將了解如何對生產系統出現的 GC 問題進行排查解決。正文 本文的內容主要如下:1. GC 基礎原理1.1.
  • HashMap面試題,看這一篇就夠了!
    序言在後端的日常開發工作中,集合是使用頻率相當高的一個工具,而其中的HashMap,則更是我們用以處理業務邏輯的好幫手,同時HashMap的底層實現和原理,也成了面試題中的常客。以前曾有詳細了解過HashMap的實現原理,看過源碼(JDK7版本)。但隨著jdk版本的飛速迭代(現在都到JDK13了,但新特性還從沒用過。。),主流的jdk使用版本也終於從JDK7挪到了JDK8。
  • Handler原理,這一篇就夠了
    前言hanlder的大概原理,可能很多人不知道,至少不清楚,網上很多文章也是到處粘貼,聽別說handler把Message發送到MessageQueue裡面去,Looper通過死循環,不斷從MessageQueue裡面獲取Message處理消息,因為Mesage.target就是當前hanlder,所以最後轉到handleMessage()方法中去處理,整個流程是這樣。