- 相關推薦
MySQL的設計架構
對于初學者可能MySQL是設計框架不是很了解，而其實在了解內存結構等。下面小編就為大家分享下MySQL的設計架構，一起來看一下吧。
在使用Impala這種所謂大數(shù)據(jù)引擎的時候，總會感覺有些地方設計的不是那么盡善盡美，比如說緩存，Impala的查詢結果是沒有經過緩存的，也就是說每次都相當于需要重新對文件執(zhí)行一遍查詢。
MySQL基本架構如下圖，是MySQL的邏輯架構圖：
最上層的服務并不是MySQL所獨有的，大多數(shù)基于網絡的客戶端/服務器的工具或者服務都有類似的架構，比如連接處理、授權認證、安全等等。
第二層架構是MySQL比較有意思的部分大多數(shù)MySQL的核心服務功能都在這一層。包括查詢解析、分析、優(yōu)化、緩存以及所有的內置函數(shù)，所有跨存儲引擎的功能都在這一層實現(xiàn)：存儲過程、觸發(fā)器、視圖等。
第三層包含了存儲引擎。存儲引擎負責MySQL中數(shù)據(jù)的存儲和提取。和GNU/Linux下的各種文件系統(tǒng)一樣，每個存儲引擎都有它的優(yōu)勢和劣勢。服務器通過API與存儲引擎進行通信。這些接口屏蔽了不同存儲引擎之間的差異。
下面挑幾個模塊解釋一下：
1.解析器
SQL命令傳遞到解析器的時候會被解析器驗證和解析。解析器是由Lex和YACC實現(xiàn)的，是一個很長的腳本。
主要功能：
將SQL語句分解成數(shù)據(jù)結構，并將這個結構傳遞到后續(xù)步驟，以后SQL語句的傳遞和處理就是基于這個結構的
如果在分解構成中遇到錯誤，那么就說明這個sql語句是不合理的
2.優(yōu)化器
SQL語句在查詢之前會使用查詢優(yōu)化器對查詢進行優(yōu)化。他使用的是“選取-投影-聯(lián)接”策略進行查詢。
用一個例子就可以理解：select uid,name from user where gender = 1;
這個select 查詢先根據(jù)where 語句進行選取，而不是先將表全部查詢出來以后再進行gender過濾
這個select查詢先根據(jù)uid和name進行屬性投影，而不是將屬性全部取出以后再進行過濾
將這兩個查詢條件聯(lián)接起來生成最終查詢結果。
3.緩存
如果查詢緩存有命中的查詢結果，查詢語句就可以直接去查詢緩存中取數(shù)據(jù)。
這個緩存機制是由一系列小緩存組成的。比如表緩存，記錄緩存，key緩存，權限緩存等。
補充知識
1.查詢優(yōu)化和執(zhí)行(Optimization and Execution)
MySQL將用戶的查詢語句進行解析，并創(chuàng)建一個內部的數(shù)據(jù)結構——分析樹，然后進行各種優(yōu)化，例如重寫查詢、選擇讀取表的順序，以及使用哪個索引等。
查詢優(yōu)化器不關心一個表所使用的存儲引擎，但是存儲引擎會影響服務器如何優(yōu)化查詢。優(yōu)化器通過存儲引擎獲取一些參數(shù)、某個操作的執(zhí)行代價、以及統(tǒng)計信息等。在解析查詢之前，服務器會先訪問查詢緩存(query cache)——它存儲SELECT語句以及相應的查詢結果集。如果某個查詢結果已經位于緩存中，服務器就不會再對查詢進行解析、優(yōu)化、以及執(zhí)行。它僅僅將緩存中的結果返回給用戶即可，這將大大提高系統(tǒng)的性能。
2.并發(fā)控制(鎖粒度)
MySQL提供兩個級別的并發(fā)控制：服務器級(the server level)和存儲引擎級(the storage engine level)。加鎖是實現(xiàn)并發(fā)控制的基本方法，MySQL中鎖的粒度：
表級鎖：MySQL獨立于存儲引擎提供表鎖，例如，對于ALTER TABLE語句，服務器提供表鎖(table-level lock)。
行級鎖：InnoDB和Falcon存儲引擎提供行級鎖，此外，BDB支持頁級鎖。InnoDB的并發(fā)控制機制，下節(jié)詳細討論。
另外，值得一提的是，MySQL的一些存儲引擎(如InnoDB、BDB)除了使用封鎖機制外，還同時結合MVCC機制，即多版本兩階段封鎖協(xié)議(Multiversion two-phrase locking protocal)，來實現(xiàn)事務的并發(fā)控制，從而使得只讀事務不用等待鎖，提高了事務的并發(fā)性。
注意： 行級鎖只在存儲引擎層實現(xiàn)，而MySQL服務器層沒有實現(xiàn)。服務器層完全不了解存儲引種的鎖實現(xiàn)。
3.事務
MySQL中，InnoDB和BDB都支持事務處理。這里主要討論InnoDB的事務處理。
事務的ACID特性：
事務是由一組SQL語句組成的邏輯處理單元，事務具有以下4個屬性，通常簡稱為事務的ACID屬性。
原子性(Atomicity)：事務是一個原子操作單元，其對數(shù)據(jù)的修改，要么全都執(zhí)行，要么全都不執(zhí)行。
一致性(Consistent)：在事務開始和完成時，數(shù)據(jù)都必須保持一致狀態(tài)。這意味著所有相關的數(shù)據(jù)規(guī)則都必須應用于事務的修改，以保持數(shù)據(jù)的完整性;事務結束時，所有的內部數(shù)據(jù)結構(如B樹索引或雙向鏈表)也都必須是正確的。
隔離性(Isolation)：數(shù)據(jù)庫系統(tǒng)提供一定的隔離機制，保證事務在不受外部并發(fā)操作影響的“獨立”環(huán)境執(zhí)行。這意味著事務處理過程中的中間狀態(tài)對外部是不可見的，反之亦然。
持久性(Durable)：事務完成之后，它對于數(shù)據(jù)的修改是永久性的，即使出現(xiàn)系統(tǒng)故障也能夠保持。
事務處理帶來的相關問題：
由于事務的并發(fā)執(zhí)行，帶來以下一些著名的問題：
更新丟失(Lost Update)：當兩個或多個事務選擇同一行，然后基于最初選定的值更新該行時，由于每個事務都不知道其他事務的存在，就會發(fā)生丟失更新問題--最后的更新覆蓋了由其他事務所做的更新。
臟讀(Dirty Reads)：一個事務正在對一條記錄做修改，在這個事務完成并提交前，這條記錄的數(shù)據(jù)就處于不一致狀態(tài);這時，另一個事務也來讀取同一條記錄，如果不加控制，第二個事務讀取了這些“臟”數(shù)據(jù)，并據(jù)此做進一步的處理，就會產生未提交的數(shù)據(jù)依賴關系。這種現(xiàn)象被形象地叫做”臟讀”。
不可重復讀(Non-Repeatable Reads)：一個事務在讀取某些數(shù)據(jù)后的某個時間，再次讀取以前讀過的數(shù)據(jù)，卻發(fā)現(xiàn)其讀出的數(shù)據(jù)已經發(fā)生了改變、或某些記錄已經被刪除了!這種現(xiàn)象就叫做“不可重復讀”。
幻讀(Phantom Reads)：一個事務按相同的查詢條件重新讀取以前檢索過的數(shù)據(jù)，卻發(fā)現(xiàn)其他事務插入了滿足其查詢條件的新數(shù)據(jù)，這種現(xiàn)象就稱為“幻讀”。
[MySQL的設計架構]
【MySQL的設計架構】相關文章：
計算機二級MySQL數(shù)據(jù)庫程序設計考試大綱08-10
公司架構應隨需而變09-07
公司架構應隨需而變10-04
公司架構應隨需而變(2)09-15
公司架構應隨需而變(2)09-18
名校留學申請文書寫作架構10-20
數(shù)據(jù)架構師崗位職責范文09-12
軟件架構師崗位職責范文11-01
軟件架構師個人簡歷模板08-11