一.概念
MySQL是一個開放源代碼的關系數據庫管理系統。原開發者為瑞典的MySQL AB公司，最早是在2001年MySQL3.23進入到管理員的視野並在之后獲得廣泛的應用。
2008年MySQL公司被Sun公司收購並發布了首個收購之后的版本MySQL5.1，該版本引入分區、基於行復制以及plugin API。
移除了原有的BerkeyDB引擎，同時，Oracle收購InnoDB Oy發布了InnoDB plugin，這后來發展成為著名的InnoDB引擎。
2010年Oracle收購Sun公司，這也使得MySQL歸入Oracle門下，之后Oracle發布了收購以后的首個版本5.5，該版本主要改善集中在性能、擴展性、復制、分區以及對windows的支持。
目前版本已發展到5.7。和其它數據庫相比，MySQL有點與眾不同，它的架構可以在多種不同場景中應用並發揮良好作用。
主要體現在存儲引擎的架構上，插件式的存儲引擎架構將查詢處理和其它的系統任務以及數據的存儲提取相分離。這種架構可以根據業務的需求和實際需要選擇合適的存儲引擎。
MySQL架構可以在多種不同場景中應用並發揮良好作用。主要體現在存儲引擎的架構上，插件式的存儲引擎架構將查詢處理和其它的系統任務以及數據的存儲提取相分離。
二.MySQL邏輯架構
數據庫管理系統結構：
MySQL是由SQL接口，解析器，優化器，緩存，存儲引擎組成的。
如下圖：
MySQL邏輯架構整體分為四層：
（1）最上層：
最上層是一些客戶端和連接服務，包含本地的sock通信和大多數基於客戶端/服務端工具實現的類似於tcp/ip的通信，主要完成一些類似於連接處理、授權認證及相關的安全方案，
在該層上引用了線程池的概念，為通過認證安全接入的客戶端提供線程。同樣在該層上可以實現基於ssl的安全鏈接。服務器也會為安全接入的每個客戶端驗證它所具有的操作權限。
（2）第二層：
第二層架構主要完成大多數的核心服務功能。如sql接口，並完成緩存的查詢。sql的分析和優化 以及部分內置函數的執行。
所有跨存儲引擎的功能也在這一層實現，如過程，函數等。在該層，服務器會解析查詢並創建相應的內部解析樹，並對其完成相應的優化如確定查詢表的順序，是否利用索引等。
最后生成相應的執行操作。如select語句，服務器還會查詢內部的緩存。如果緩存空間足夠大，這樣就解決大量讀操作的環境中能夠很好的提升系統的性能。
（3）存儲引擎層：
存儲引擎真正的負責MySQL中數據的存儲和提取，服務器通過API與存儲引擎進行通信，不同的存儲引擎具有的功能不同，這樣可以根據自己的實際需進行選取。
（4）數據存儲層：
主要是將數據存儲在運行於裸設備的文件系統之上，並完成於存儲引擎的交互。
三.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命令傳遞到解析器的時候會被解析器驗證和解析。
主要功能：
（1）將SQL語句分解成數據結構，並將這個結構傳遞到后續步驟，后面SQL語句的傳遞和處理就是基於這個結構的；
（2）如果在分解構成中遇到錯誤，那么就說明這個sql語句是不合理的，語句將不會繼續執行下去。
6、Optimizer (查詢優化器)
SQL語句在查詢之前會使用查詢優化器對查詢進行優化(產生多種執行計划，最終數據庫會選擇最優化的方案去執行，盡快返會結果) 他使用的是“選取-投影-聯接”策略進行查詢。
用一個例子就可以理解： select uid,name from user where gender = 1；
這個select 查詢先根據where 語句進行選取，而不是先將表全部查詢出來以后再進行gender過濾，
這個select查詢先根據uid和name進行屬性投影，而不是將屬性全部取出以后再進行過濾，將這兩個查詢條件聯接起來生成最終查詢結果。
7、Cache和Buffer (查詢緩存)
如果查詢緩存有命中的查詢結果，查詢語句就可以直接去查詢緩存中取數據。這個緩存機制是由一系列小緩存組成的。比如表緩存，記錄緩存，key緩存，權限緩存等。
9、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）處理，存儲引擎將會到后端的存儲設備中取得相應的數據，並原路返回給程序。
Sql語句執行過程圖解：
注意點：
（1）如何緩存查詢數據
存儲引擎處理完數據，並將其返回給程序的同時，它還會將一份數據保留在緩存中，以便更快速的處理下一次相同的請求。
具體情況是，mysql會將查詢的語句、執行結果等進行hash，並保留在cache中，等待下次查詢。
（2）buffer與cache的區別
從mysql原理圖可以看到，緩存那里實際上有buffer和cache兩個，那它們之間的區別：簡單的說就是，buffer是寫緩存，cache是讀緩存。
（3）如何判斷緩存中是否已緩存需要的數據
這里可能有一個誤區，覺得處理SQL語句的時候，為了判斷是否已緩存查詢結果，會將整個流程走一遍，取得執行結果后再與需要的進行對比，看看是否命中，
並以此說，既然不管緩存中有沒有緩存到查詢內容，都要整個流程走一遍，那緩存的優勢在哪？
其實並不是這樣，在第一次查詢后，mysql便將查詢語句以及查詢結果進行hash處理並保留在緩存中，SQL查詢到達之后，對其進行同樣的hash處理后，
將兩個hash值進行對照，如果一樣，則命中，從緩存中返回查詢結果；否則，需要整個流程走一遍。
首先要清楚redo log和binlog兩個日志模塊
1、redo log（InnoDB特有的日志模塊） 重做日志文件，用於記錄事務操作的變化，記錄修改后的值，不管事務是否提交。保證數據的完整性。
其中redo log是固定大小的，是從頭開始寫，寫到末尾在從頭開始。同時會有兩個指針，一個記錄寫入的位置，一個標記，當前擦除的位置，不斷的循環。
整個過程稱為crash-safe。即時數據庫異常，也會有記錄
2、binlog 歸檔日志文件，用於記錄對mysql數據庫執行更改的所有操作。binlog是追加寫，不會覆蓋之前的。
接下來介紹一下mysql更新一條語句的流程。
update tb_area SET area_name = "beijing" WHERE area_id = 1
（1）首先執行器通過id查到這條記錄（搜索樹或者查找數據頁） ，並加載到內存中。
（2）然后對這條記錄的area_name調用引擎寫入接口，進行修改。
（3）修改內存中的值，同時更新redolog告知執行器完成寫入（狀態置為prepare），可以提交事務，執行器將這條操作記錄記錄在binlog，寫入磁盤
（4）完成上述一系列的操作，執行器調用事務提交接口（redolog狀態置為commit），完成更新操作。
注意：
Mysql的redolog模塊寫入拆成2步走，prepare和commit，稱為兩階段提交。
整個過程為1、redolog的prepare狀態 2、binlog的寫入 3、redolog的commit狀態，保證Mysql的可靠性。
如果binlog沒有寫入並沒有提交事務回滾，如果binlog寫入事務沒提交，數據庫回復后自動完成commit。
四.並發控制和鎖的概念
Mysql 中的並發控制在存儲引擎層實現。
解決並發問題最有效的方案是鎖的機制。
鎖在功能上分為：
（1）共享鎖（shared lock）既讀鎖，可以允許其他select操作；
（2）排它鎖（exclusive lock）既寫鎖，不允許任何其他操作；
鎖在粒度上分為：
（1）表級鎖（table lock），鎖定表；
（2）行級鎖（row lock），鎖定行；
Mysql中大多數事務型存儲引擎都不是簡單的行級鎖，給予性能的考慮，一般都同事實現了 多版本並發控制（MVCC）。
當數據庫中有多個操作需要修改同一數據時，不可避免的會產生數據的臟讀。這時就需要數據庫具有良好的並發控制能力，這一切在MySQL中都是由服務器和存儲引擎來實現的。
解決並發問題最有效的方案是引入了鎖的機制，鎖在功能上分為共享鎖(shared lock)和排它鎖(exclusive lock)即通常說的讀鎖和寫鎖。
當一個select語句在執行時可以施加讀鎖，這樣就可以允許其它的select操作進行，因為在這個過程中數據信息是不會被改變的這樣就能夠提高數據庫的運行效率。
當需要對數據更新時，就需要施加寫鎖了，不在允許其它的操作進行，以免產生數據的臟讀和幻讀。
鎖同樣有粒度大小，有表級鎖(table lock)和行級鎖(row lock)，分別在數據操作的過程中完成行的鎖定和表的鎖定。這些根據不同的存儲引擎所具有的特性也是不一樣的。
MySQL大多數事務型的存儲引擎都不只是簡單的行級鎖，基於性能的考慮，他們一般在行級鎖基礎上實現了多版本並發控制(MVCC)。
這一方案也被Oracle等主流的關系數據庫采用。它是通過保存數據中某個時間點的快照來實現的，這樣就保證了每個事務看到的數據都是一致的。詳細的實現原理可以參考《高性能MySQL》第三版。
五.事務
簡單的說事務就是一組原子性的SQL語句。可以將這組語句理解成一個工作單元，要么全部執行要么都不執行。默認MySQL中自動提交時開啟的（start transaction）。
操作事務：
事務具有ACID的特性：
（1）原子性：
事務中的所有操作要么全部提交成功，要么全部失敗回滾。
比如從取款機取錢,這個事務可以分成兩個步驟：1划卡，2出錢，不可能划了卡，而錢卻沒出來，這兩步必須同時完成，要么就不完成。
（2）一致性：
數據庫總是從給一個一致性的狀態轉換到另一個一致性的狀態
例如：完整性約束了a+b=10，一個事務改變了a，那么b也應該隨之改變，不管數據怎么改變。一定是符合約束。
（3）隔離性：
一個事務所做的修改在提交之前對其它事務是不可見的，兩個以上的事務不會出現交錯執行的狀態.因為這樣可能會導致數據不一致。
（4）持久性：
一旦事務提交，其所做的修改便會永久保存在數據庫中。
事務的隔離級別：
（1）READ UNCOMMITTED(讀未提交)：事務中的修改即使未提交也是對其它事務可見；
（2）READ COMMITTED(讀提交)：事務提交后所做的修改才會被另一個事務看見，可能產生一個事務中兩次查詢的結果不同。
（3）REPEATABLE READ(可重讀)：只有當前事務提交才能看見另一個事務的修改結果。解決了一個事務中兩次查詢的結果不同的問題。
（4）SERIALIZABLE(串行化)：只有一個事務提交之后才會執行另一個事務。
查詢並修改隔離級別：
死鎖：
兩個或多個事務在同一資源上相互占用並請求鎖定對方占用的資源，從而導致惡性循環的現象。
對於死鎖的處理：MySQL的部分存儲引擎能夠檢測到死鎖的循環依賴並產生相應的錯誤。InnoDB引擎解決的死鎖的方案是將持有最少寫鎖的事務進行回滾。
為了提供回滾或者撤銷未提交的變化的能力，許多數據源采用日志機制。例如：sql server使用一個預寫事務日志，在將數據應用於（或提交到）實際數據頁面前，先寫在事務日志上。
但是，其他一些數據源不是關系型數據庫管理系統，他們管理未提交事務的方式完全不同。只要事務回滾時，數據源可以撤銷所有未提交的改變，那么這種技術可用於事務管理。
六.MySQL存儲引擎及應用方案
MySQL采用插件式的存儲引擎的架構，可以根據不同的需求為不同的表設置不同的存儲引擎。
如：
相關字段介紹：
Name：顯示的是表名。
Engine：顯示存儲引擎，該表存儲引擎為MyISAM。
Row_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：額外的一些注釋信息，根據存儲引擎的不同表示的內容也不脛相同。
常用MySQL存儲引擎介紹：
（1）InnoDB引擎：
將數據存儲在表空間中，表空間由一系列的數據文件組成，由InnoDb管理，支持每個表的數據和索引存放在單獨文件中(innodb_file_per_table)；
支持事務，采用MVCC來控制並發，並實現標准的4個事務隔離級別，支持外鍵。索引基於聚簇索引建立，對主鍵查詢有較高性能。
數據文件的平台無關性，支持數據在不同的架構平台移植；能夠通過一些工具支持真正的熱備，如XtraBackup等；
內部進行自身優化如采取可預測性預讀，能夠自動在內存中創建bash索引等。
（2）MyISAM引擎：
MySQL5.1默認，不支持事務和行級鎖，提供大量的特性如全文索引、空間函數、壓縮、延遲更新等。
數據庫故障后，安全恢復性，對於只讀數據可以忍受故障恢復，MyISAM依然非常適用。
日志服務器的場景也比較適用，只需插入和數據讀取操作，不支持單表一個文件，會將所有的數據和索引內容分別存放在兩個文件中。
MyISAM對整張表加鎖而不是對行，所以不適用寫操作比較多的場景，支持索引緩存不支持數據緩存。
（3）Archive 引擎：
只支持 insert 和 select 操作；
緩存所有的寫數據並進行壓縮存儲，支持行級鎖但不支持事務；
適合高速插入和數據壓縮，減少 IO 操作，適用於日志記錄和歸檔服務器。
（4）Blackhole 引擎：
沒有實現任何存儲機制，會將插入的數據進行丟棄，但會存儲二進制日志；
會在一些特殊需要的復制架構的環境中使用。
（5）CSV 引擎：
可以打開 CSV 文件存儲的數據，可以將存儲的數據導出，並利用 excel 打開；
可以作為一種數據交換的機制，同樣經常使用。
（6）Memory 引擎：
將數據在內存中緩存，不消耗 IO ；
存儲數據速度較快但不會被保留，一般作為臨時表的存儲被使用。
（7）Federated 引擎：
能夠訪問遠程服務器上的數據的存儲引擎。
能夠建立一個連接連到遠程服務器。
（8）Mrg_MyISAM 引擎：
將多個 MYISAM 表合並為一個。
本身並不存儲數據，數據存在 MyISAM 表中間。
（9）NDB 集群引擎：
MySQL Cluster 專用。
存儲引擎選取參考因素：
（1）是否有事務需求
如果需要事務支持最好選擇 InnoDB 或者 XtraDB ，如果主要是 select 和 insert 操作 MyISAM 比較合適，一般使用日志型的應用。
（2）備份操作需求
如果能夠關閉服務器進行備份，那么該因素可以忽略，如果需要在線進行熱備份，則 InnoDB 引擎是一個不錯的選擇。
（3）故障恢復需求
在對恢復要求比較好的場景中推薦使用 InnoDB ，因為 MyISAM 數據損壞概率比較大而且恢復速度比較慢。
（4）性能上的需求
有些業務需求只有某些特定的存儲引擎才能夠滿足，如地理空間索引也只有 MyISAM 引擎支持。
所以在應用架構需求環境中也需要管理員折衷考慮，當然從各方面比較而言， InnoDB 引擎還是默認應該被推薦使用的。