mysql事務能夠理解爲一系列操做,要麼成功執行,要麼失敗。html
小結:不可重複讀的和幻讀很容易混淆,不可重複讀側重於修改,幻讀側重於新增或刪除。解決不可重複讀的問題只需鎖住知足條件的行,解決幻讀須要鎖表mysql
MyISAM: 節約空間,讀取響應速度快,表應用於讀的場景比較多,支持FULLTEXT類型的索引數據庫
InnoDB: 若是應用程序須要用到事務,使用外鍵或須要更高的安全性,以及須要容許不少用戶同時 修改某個數據表裏的數據,則InnoDB數據表更值得考慮。支持行鎖(某些狀況下仍是鎖整表,如 update table set a=1 where user like '%lee%'安全
Memory: 存儲在內存中,因此沒有持久化。能夠用於test中假數據的讀寫數據結構
實例:公司之前的一張表用的是MyISAM,忽然有一天這張表不能讀寫幾個小時。公司上下折騰了很久。最後緣由是這張表用的是MyISAM,同時正好有人向表中新加入一列,同時進行索引,因爲表很大,因此一直在作索引。所以整張表一直處於鎖的狀態。併發
在MySQL執行語句中,插入或者更新操做不多有性能問題
大部分性能問題都是複雜的查詢操做致使的。緣由的話要從sql讀取數聽說起:性能
數據庫數據保存在磁盤上,每次讀取數據,爲了提升性能,須要把部分數據讀取到內存來計算。
然而磁盤讀取很是慢,因此每次讀取IO都會讀取相鄰的數據,稱之爲每次讀取一頁數據(page, 4k/8k)
基於以上原理,咱們要設計得是每次查詢都能使磁盤IO最小,所以b+樹知足條件:spa
圖中比較重要的幾點:設計
如圖所示,若是要查找數據項29,那麼首先會把磁盤塊1由磁盤加載到內存,此時發生一次IO,在內存中用二分查找肯定29在17和35之間,鎖定磁盤塊1的P2指針,內存時間由於很是短(相比磁盤的IO)能夠忽略不計,經過磁盤塊1的P2指針的磁盤地址把磁盤塊3由磁盤加載到內存,發生第二次IO,29在26和30之間,鎖定磁盤塊3的P2指針,經過指針加載磁盤塊8到內存,發生第三次IO,同時內存中作二分查找找到29,結束查詢,總計三次IO。真實的狀況是,3層的b+樹能夠表示上百萬的數據,若是上百萬的數據查找只須要三次IO,性能提升將是巨大的,若是沒有索引,每一個數據項都要發生一次IO,那麼總共須要百萬次的IO,顯然成本很是很是高。
當b+樹的數據項是複合的數據結構,好比(name,age,sex)的時候,b+數是按照從左到右的順序來創建搜索樹的,好比當(張三,20,F)這樣的數據來檢索的時候,b+樹會優先比較name來肯定下一步的所搜方向,若是name相同再依次比較age和sex,最後獲得檢索的數據;但當(20,F)這樣的沒有name的數據來的時候,b+樹就不知道下一步該查哪一個節點,由於創建搜索樹的時候name就是第一個比較因子,必需要先根據name來搜索才能知道下一步去哪裏查詢。好比當(張三,F)這樣的數據來檢索時,b+樹能夠用name來指定搜索方向,但下一個字段age的缺失,因此只能把名字等於張三的數據都找到,而後再匹配性別是F的數據了, 這個是很是重要的性質,即索引的最左匹配特性。
索引及explain詳解
好的話點個贊吧!!!