MySql的架構和歷史

架構為如下：

儲存引擎：負責資料的儲存和提取，供了幾十個api供服務層進行呼叫。各個儲存引擎之間不會進行互動，只是供服務層進行呼叫。事務控制和鎖的管理也是在儲存引擎裡面進行。

服務層：乙個sql過來之後，會在服務層進行解析，建立解析樹，呼叫底層的儲存引擎得到各種開銷資訊和統計資訊，進行各種優化，決定表的讀取順序以及選擇合適的索引。

1.2  併發控制

1、mysql通過加讀鎖和寫鎖來進行併發控制。

2、鎖的粒度

表鎖併發程度低，鎖的開銷小alter table  會加表鎖

行級鎖併發程度高，但是鎖的開銷大

3、鎖的控制是在儲存引擎裡面實現的，所以不同的儲存引擎加鎖的順序是不一樣的，有的能引起死鎖有的則不會。

原子性：乙個事務的操作要麼全部執行成功，要麼全部失敗回滾。

一致性：在執行事務的第3,4條語句的時候資料庫崩潰了，資料還是一致的。

隔離性：乙個事務的操作對另乙個事務的可見性。mysql預設為可重複讀。

永續性：一旦事務提交，其所做的修改就會永久的同步到資料庫中。

read  uncommited（讀未提交）   造成髒讀

read commited（提交讀）        造成不可重複讀

oracle和sql  server預設是這種級別

repeatable    read（可重複讀）   造成幻讀

mysql預設是此級別（通過mvcc和鎖機制）   

mysql通過mvcc和間隙鎖解決了幻讀的問題

seriable（可序列化）

事務是序列執行的

因為請求資源的方式不一致可能導致死鎖

資料庫系統實現死鎖檢測，解除死鎖，和請求鎖超時等機制。

如果死鎖發生，會將含有最少行級鎖的事務進行回滾來解除死鎖。

因為更新資料到磁碟上資料分布的不均勻，所以花費的時間比較長。但是可以將操作以日誌的形式新增到日誌檔案末尾，日誌的儲存操作是有序的。這能加快速度。

1、預設每個連線都是autocommit，可以在建立連線之後通過命令 show variables  like  'autocommit'來檢視當前的狀態。

可以通過 set  autocommit=0來設定事務不是自動提交的。那麼所有查詢都是在乙個事務裡，直到顯式的進行提交或者進行回滾。

2、一些操作會自動提交當前的事務，如alter table，lock   tables

3、設定事務的隔離級別（可以設定全域性的和會話級別的）

可以通過set  transaction isolation  level來設定全域性的事務隔離級別

可以通過set session      transaction isolation  level  設定本鏈結的隔離級別，並在下次事務中生效。

1、不推薦這樣使用

2、如果乙個事務同時操作支援事務的儲存引擎表和不支援事務的儲存引擎表，如果事務成功提交則沒什麼問題。如果事務回滾，則支援事務的儲存引擎錶能回滾，但是不支援事務的儲存引擎表不能回滾，會造成資料一致性問題。

Mysql的架構和歷史（二）

事務 隔離級別 sql標準定義了四種隔離級別 read uncommitted 未提交讀 在這個級別中所有事務可以讀取到當前事務對資料所正在進行的修改操作。read committed 提交讀 該級別，所有事務只能讀取到事務提交之後的資料只要事務沒有提交的話，那麼其他事務是不可見的，這個級別也叫作不...

Mysql歷史架構筆記

開發5.0版，他將增加儲存過程 伺服器端游標，觸發器，檢視，xa事務，查詢優化器重大改進及許多其他特性。2004年10月4.1版穩定了 5.0版則在一年以後變得穩定，時間是2005年10月。mysql的架構 核心模組 可在伺服器識別出下列模組 伺服器初始化模組 連線管理器 執行緒管理器 使用者驗證模...

MySQL架構與歷史

所以基於此，資料庫實現了各種死鎖檢測和死鎖超時機制目前innodb採取的方案是 將持有最少行級排他鎖的事務進行回滾。處理死鎖 大多數情況下只需要重新執行因死鎖回滾的事務即可。事務日誌 mysql中的事務 一般建議 除非禁用了自動提交 才可以使用lock tables之外 其他熱河時候都不要顯示的執行...