Mysql基本原理

時間 2019-11-07

原文原文鏈接

MYSQL基本邏輯架構

都是英文
解釋一下
1.Native C API .Net PHP Pecl Python 等爲服務端腳本語言
2.connection Pool 鏈接池
1.authentication 認證
2.thread reuse 線程重用
3.nnection limits 鏈接限制
4.check Memory 檢查存儲器
5.caches 速緩存
3.nagement services & utillties管理服務與利用
4.sql interface SQL接口
1.DML DDL 讀寫請求
2.stored procedures 存儲過程
3.Views 意見
4.triggers 觸發器
5.etc 等mysql

5.Parser 語法分析器
Query translation 查詢翻譯
Object Privilege 對象特權
6.Optimizer 優化器
Access Paths 訪問路徑
Statistics 統計
7.Caches & Buffers 緩存與緩衝區
Global and Engine 全局引擎
Specific Caches 特定緩存
buffers 緩衝器
8.MYISAM INNODB Memory 等屬於各類表引擎
Pluggable Storage Engines 可插拔存儲引擎
Memory 記憶 Index 索引 Storage Management 存儲管理
9.File system Files & Logs
file system 文件系統 files & log 文件及日誌
Redo 重作日誌
1.INE Redo log 在線重作日誌(online redo log )主要用於：Oracle數據庫所在服務器忽然掉電、忽然重啓或者執行shutdown abort等命令使得在服務器從新啓動以後，Oracle數據庫沒有辦法正常的啓動實例。此時，在線重作日誌就派上了用場，Oracle會使用在線重作日誌，把數據庫恢復到服務器掉電前的那一個時刻，從而使得數據庫能正常的啓動起來。
在Oracle數據庫中，默認狀況下，至少會有兩個重作日誌組，並且每一個組裏面至少包含了一個重作日誌文件。日誌組不會自動增長，在一個寫滿以後，會自動去寫下一個。在下一個被寫滿以後會又從第一個開始寫起。
2.Archive redo log 歸檔日誌(archive log)主要用於硬件級別的錯誤：磁盤的壞道致使沒法讀寫、寫入的失敗、磁盤受損致使數據庫數據丟失。這就要使用歸檔日誌文件，經過歸檔日誌文件，把數據庫恢復到歸檔日誌所在的時間點上而後再經過在線重作日誌文件把數據庫恢復到當前的時間點上。
對於歸檔日誌文件，能夠理解爲在線重作日誌文件的備份。即當一個重作日誌文件被填滿了以後，歸檔日誌文件就會把其備份保留一份。（由於上面說了，在線重作日誌文件會自動的覆蓋）因此，歸檔日誌文件就是舊的在線日誌文件的備份。算法

Undo 回滾數據
撤銷（Undo）數據是反轉DML語句結果所需的信息。撤銷數據一般被稱爲「回滾數據」，在過去的Oracle版本中，「回滾數據」和「撤銷數據」能夠交替使用，但從 9i版本開始，這兩個術語有所不一樣：功能相同，但管理方式不一樣。只要某個事務修改了數據，那麼更新前的原有數據就會被寫入一個回滾段或撤銷段。回滾段在 11g版本中依然存在，但從9i版本開始，Oracle數據庫引入了可供選擇的撤銷段。Oracle強烈建議全部數據庫都應當使用撤銷段，回滾段只被保留用於向後兼容。
管理Undo編輯
1.與Undo相關的錯誤條件
管理撤銷的原則十分簡單：首先，應當始終存在容許全部事務繼續進行的足夠撤銷空間；其次，應當始終存在保證查詢成功的足夠撤銷數據。若是某個事務耗盡了撤銷空間，那麼這個事務就會因爲Oracle錯誤「ORA-30036 unable to extend segment in undo tablespace（沒法擴展撤銷表空間內的撤銷段）」而失敗。
2.用於Undo管理與Undo保留保證的參數
下面3個初始化參數能夠控制撤銷：
UNDO_MANAGEMENT：默認爲manual，就是不會使用撤銷段。默認設置是爲了實現向後兼容性，最後不要使用默認。建議設置爲 AUTO，啓用使用撤銷段的自動撤銷管理。參數是靜態的。
UNDO_TABLESPACE：若是使用了「UNDO_MANAGEMENT=AUTO」，就必定要指定該參數。該參數指定了一個做爲有效撤銷表空間的表空間，而且該表空間必須已被建立爲一個撤銷表空間，同時其內部的全部撤銷段都會被自動聯機。
UNDO_RETENTION：可選，以秒爲單位進行設置的參數。指定了保留過時撤銷數據的目標位置。若是配置了保證撤銷保留，那麼該參數就不是可選的。針對撤銷的默認模式是：對於事務與查詢來講，Oracle更傾向於維護事務。10G版本中存在保證撤銷保留的選項，意味着通過 UNDO_RETENTION參數所指定的時間以前，撤銷數據決不會被重寫。
3.調整與監視Undo表空間
撤銷表空間應當足夠大，算法的話，首先計算在最高工做負荷時生成撤銷的速度，而後再乘以耗時最長的查詢的時間長度。
4.刪除與縮小Undo表空間
建立一個撤銷表空間時，Oracle會在這個表空間內建立一個撤銷段池。
Data 數據
Index 索引
Binary 二進制
Error 錯誤
Query and Slow 慢查詢sql

1.最上層是一些客戶端和鏈接服務，包含本地sock通訊和大多數基於客戶端/服務端工具實現的相似於tcp/ip的通訊。主要完成一些相似於鏈接處理、受權認證、及相關的安全方案。在該層上引入了線程池的概念，爲經過認證安全接入的客戶端提供線程。一樣在該層上能夠實現基於SSL的安全連接。服務器也會爲安全接入的每一個客戶端驗證它所具備的操做權限。數據庫

2.第二層架構主要完成大多少的核心服務功能，如SQL接口，並完成緩存的查詢，SQL的分析和優化及部份內置函數的執行。全部跨存儲引擎的功能也在這一層實現，如過程、函數等。在該層，服務器會解析查詢並建立相應的內部解析樹，並對其完成相應的優化如肯定查詢表的順序，是否利用索引等，最後生成相應的執行操做。若是是select語句，服務器還會查詢內部的緩存。若是緩存空間足夠大，這樣在解決大量讀操做的環境中可以很好的提高系統的性能。緩存

3.存儲引擎層，存儲引擎真正的負責了MySQL中數據的存儲和提取，服務器經過API與存儲引擎進行通訊。不一樣的存儲引擎具備的功能不一樣，這樣咱們能夠根據本身的實際須要進行選取。安全

4.數據存儲層，主要是將數據存儲在運行於裸設備的文件系統之上，並完成與存儲引擎的交互。服務器

3.併發控制和鎖的概念
當數據庫中有多個操做須要修改同一數據時，不可避免的會產生數據的髒讀。這時就須要數據庫具備良好的併發控制能力，這一切在MySQL中都是由服務器和存儲引擎來實現的。
解決併發問題最有效的方案是引入了鎖的機制，鎖在功能上分爲共享鎖(shared lock)和排它鎖(exclusive lock)即一般說的讀鎖和寫鎖。當一個select語句在執行時能夠施加讀鎖，這樣就能夠容許其它的select操做進行，由於在這個過程當中數據信息是不會被改變的這樣就可以提升數據庫的運行效率。當須要對數據更新時，就須要施加寫鎖了，不在容許其它的操做進行，以避免產生數據的髒讀和幻讀。鎖一樣有粒度大小，有表級鎖(table lock)和行級鎖(row lock)，分別在數據操做的過程當中完成行的鎖定和表的鎖定。這些根據不一樣的存儲引擎所具備的特性也是不同的。
MySQL大多數事務型的存儲引擎都不是簡單的行級鎖，基於性能的考慮，他們通常都同時實現了多版本併發控制(MVCC)。這一方案也被Oracle等主流的關係數據庫採用。它是經過保存數據中某個時間點的快照來實現的，這樣就保證了每一個事務看到的數據都是一致的。詳細的實現原理能夠參考《高性能MySQL》第三版。架構

相關內容

4.事務
1.簡單的說事務就是一組原子性的SQL語句。能夠將這組語句理解成一個工做單元，要麼所有執行要麼都不執行。
2.事務具備ACID的特性：
原子性(atomicity):事務中的全部操做要麼所有提交成功，要麼所有失敗回滾。
一致性(consistency):數據庫老是從一個一致性狀態轉換到另外一個一致性狀態。
隔離性(isolation):一個事務所作的修改在提交以前對其它事務是不可見的。
持久性(durability):一旦事務提交，其所作的修改便會永久保存在數據庫中。
3.事務的隔離級別：在SQL標準中定義了四種隔離級別： READ UNCOMMITTED(讀未提交)：事務中的修改即便未提交也是對其它事務可見
READ COMMITTED(讀提交)：事務提交後所作的修改纔會被另外一個事務看見，可能產生一個事務中兩次查詢的結果不一樣。
REPEATABLE READ(可重讀)：只有當前事務提交才能看見另外一個事務的修改結果。解決了一個事務中兩次查詢的結果不一樣的問題。
SERIALIZABLE(串行化)：只有一個事務提交以後纔會執行另外一個事務。
show variables like 'tx_isolation'; 查看事務級別
set tx_isolation = ‘READ-COMMITTED' 設置事務級別
4.死鎖：兩個或多個事務在同一資源上相互佔用並請求鎖定對方佔用的資源，從而致使惡性循環的現象。MySQL的部分存儲引擎可以檢測到死鎖的循環依賴併產生相應的錯誤。InnoDB引擎解決死鎖的方案是將持有最少排它鎖的事務進行回滾。併發

Mysql 儲存引擎及應用方案
mysql採用插件式的存儲引擎架構，能夠根據不一樣的需求爲不一樣的表設置不一樣的存儲引擎。
show table status like demo\G 查看錶引擎
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：額外的一些註釋信息，根據存儲引擎的不一樣表示的內容也不脛相同。tcp

Mysql 各類表引擎
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專用。

5.存儲引擎選取參考因素
1.是否須要事務支持 INNODB
2.是否有備份操做需求熱備份 INNODB
3.故障恢復需求在對恢復要求比較好的場景中推薦使用InnoDB，由於MyISAM數據損壞機率比較大並且恢復速度比較慢。
4.性能上的需求有些業務需求只有某些特定的存儲引擎纔可以知足，如地理空間索引也只有MyISAM引擎支持。因此在應用架構需求環境中也須要管理員折衷考慮，固然從各方面比較而言，InnoDB引擎仍是默認應該被推薦使用的。

6.表引擎修改方法
alter table demo engine = InnoDB

7.Mysql 導入導出 mysqldump