每個客戶端連線都會有乙個執行緒
認證基於使用者名稱,原始主機資訊和密碼
mysql會解析查詢並進行優化
對於select會先檢查查詢快取,能夠找到就直接返回結果集
鎖在commit或rollback時自動釋放
共享,不阻塞,多個使用者可以同時讀同乙個資源
保證只有乙個使用者寫入,防止其他使用者寫入或讀取資料
加鎖,鎖的檢查,鎖的解除都是要消耗系統資源的
加鎖的物件大小成為鎖粒度
在鎖的開銷與資料的安全性中尋求平衡
最大程度支援併發,mysql伺服器層沒有實現,由儲存引擎實現
開銷最小
mysql伺服器可以根據自己的目的加上表鎖而忽略儲存引擎的鎖機制
一組原子性的sql語句,要麼全部執行,要麼全部不執行
acid
原子性:要麼全部執行,要麼全部不執行
一致性:狀態的改變是完全的,不存在改變一半就被儲存的情況
隔離性:在提交前對其他事務不可見
永續性:資料更改會永遠儲存
即使事務未曾提交,資料對於其他事務也是可見的.即事務可以讀取未提交的資料,也叫髒讀或讀髒資料
即乙個事務在提交之前,改變對其他事務是不可見的,又叫不可重複讀,幻讀(在乙個事務讀取資料後還未提交時,另乙個事務更改了資料)
解決了幻讀和髒讀的問題
強制事務序列執行,給每一行資料加鎖
死鎖指兩個或多個事務在同乙個資源上相互占用,並請求鎖定對方占用的資源,從而造成的惡性迴圈
死鎖發生後,只能通過部分或完全回滾事務才能解決
例子
避免頻繁從記憶體向磁碟中寫入資料(可以記錄下日誌操作,在後台慢慢一次寫入,所以日誌檔案是追加寫)
便於出現故障後的恢復
innodb:支援事務
myisam:不支援事務
不支援事務的表回滾不能撤銷更改
顯式:自動加鎖
隱式:主動加鎖
是mysql的預設事務型引擎,也是使用最廣泛的儲存引擎,被設計用來處理大量短期事務
不支援事務和行級鎖
資料庫崩潰後無法安全恢復
對整張表加鎖,而不是針對行,但在讀取資料的時候依然可以插入新的資料(併發插入)
延遲更新索引鍵
用於轉化.csv檔案成資料庫裡的表
除非用到某些innodb不具備的特性,並且沒有其他辦法可以替代,否則都應該優先選擇innodb引擎
最好不要混用多種儲存引擎!!!
alter table name engine = innodb
MySQL架構與歷史
所以基於此，資料庫實現了各種死鎖檢測和死鎖超時機制目前innodb採取的方案是 將持有最少行級排他鎖的事務進行回滾。處理死鎖 大多數情況下只需要重新執行因死鎖回滾的事務即可。事務日誌 mysql中的事務 一般建議 除非禁用了自動提交 才可以使用lock tables之外 其他熱河時候都不要顯示的執行...
mysql架構與歷史
最上層的服務並不是mysql獨有的，大多數基於網路的客戶端 服務端的工具或者服務都有類似的架構。比如連線處理 授權認證 安全等等 第二層架構是mysql比較有意思的部分，大多數mysql的核心功能都在這一層實現。其中分析器 優化器 執行器統稱為解析器。所有的內建函式 跨儲存引擎的功能都在這一層實現 ...
Mysql歷史架構筆記
開發5.0版，他將增加儲存過程 伺服器端游標，觸發器，檢視，xa事務，查詢優化器重大改進及許多其他特性。2004年10月4.1版穩定了 5.0版則在一年以後變得穩定，時間是2005年10月。mysql的架構 核心模組 可在伺服器識別出下列模組 伺服器初始化模組 連線管理器 執行緒管理器 使用者驗證模...