1.Innodb存儲引擎java
支持事務,其特色是行鎖設計、支持外鍵。mysql
Innodb是Mysql默認的存儲引擎。算法
2.MyISAM存儲引擎sql
MyIsam存儲引擎不支持事務和表鎖設計,可是支持全文索引。數據庫
1.常見的索引:B+樹索引、全文索引、哈希索引。數組
2.B+樹,是經過二叉查找樹,再由平衡二叉樹,B樹演化而來。數據結構
二叉查找樹:左子樹的值老是小於根的值,右子樹的值老是大於根的值。能夠經過中序遍歷獲得值的排序輸出。架構
平均查找速度比順序查找來得快。函數
平衡二叉樹:首先符合二叉查找樹的定義,其次必須知足任何節點的兩個子樹的高度的最大差爲1。優化
B+樹:是爲磁盤或其餘直接存取輔助設備設計的一種平衡樹。
在B+樹中,全部記錄節點都是按鍵值對的大小順序存放在同一層的葉子節點上,由各葉子節點指針進行鏈接。
優勢:B+樹的高度通常都在2--4層。也就是查找某一鍵值的行記錄時最多隻須要2--4次IO就能夠了。
B+樹索引,分爲彙集索引和輔助索引。
彙集索引和輔助索引的區別:葉子節點存放的是不是一整行的信息。
彙集索引:就是按照每張表的主鍵構造一顆B+樹,同時葉子節點存放的即爲整張表的行記錄數據,也將彙集索引的葉子節點稱爲數據頁。
輔助索引:葉子節點並不包含行記錄的所有數據。葉子節點除了包含鍵值之外,每一個葉子節點中的索引行中還包含了一個書籤(bookmark)。該書籤用來告訴Innodb存儲引擎哪裏能夠找到與索引相對應的行數據。輔助索引的書籤就是相應行數據的彙集索引鍵。
1.SHOW INDEX FROM 表名
:該語句能夠查看錶的索引信息。
2.Cardinality值很是關鍵,優化器會根據這個值來判斷是否使用這個索引。
對於性別,地區類型的字段,可取值的範圍小,稱爲「低選擇性」,沒有必要使用B+樹索引。
Cardinality值,表示索引中不重複記錄數量的預估值。在實際運用中,Cardinality儘量地接近1。若是很是小,用戶須要考慮是否還有必要建立這個索引。
能夠查看查詢類型,以及索引。
PROSSIBLE_KEY:可能的索引。
KEY:實際的索引。
1.聯合索引是指對錶上的多個列進行索引。
2.聯合索引也是一顆B+樹,不一樣的是聯合索引的鍵值的數量不是1,而是大於等於2。
聯合索引的鍵值都是排序的。經過葉子節點能夠邏輯上順序地讀出全部數據。
數據按(a,b)進行存放,排序方式相似於(1,1)、(1,2)、(2,1)、(2,4)、(3,1)、(3,2)、(4,1)。
對於單個的a列查詢來講,可使用(a,b)這個聯合索引。
但對於單個的b列查詢來講,則不可使用(a,b)這個聯合索引,由於葉子節點上的b值爲1,2,1,4,1,2,顯然不是排序的。
3.索引的第二個好處是已經對第二個鍵值進行了排序。
4.對於聯合索引(a,b,c)來講,如下語句能夠直接經過聯合索引獲得結果。
SELECT * FROM TABLE WHERE a=XXX ORDER BY b SELECT * FROM TABLE WHERE a=XXX AND b=XXX ORDER BY c
可是如下的則不行:
SELECT * FROM TABLE WHERE a=XXX ORDER BY c
1.InnoDBd存儲引擎支持覆蓋索引,即從輔助索引中就能夠獲得查詢的記錄,而不須要查詢彙集索引中的記錄。
使用覆蓋索引的一個好處是,輔助索引不包含整行記錄的全部信息,故其大小要遠小於彙集索引,所以能夠減小大量的IO操做。
1.FIC : Fast Index Creation。
2.Online DDL
1.哈希表也成爲散列表。由直接尋址表改進而來。
哈希表,利用哈希函數h,根據關鍵字k計算出槽的位置。
2.哈希碰撞:兩個不一樣的關鍵字,可能映射到同一槽中。成爲「碰撞」。
解決碰撞的方法:鏈表法。把同一哈希槽中的全部元素放在一個鏈表中,
在槽中有一個指針j,指向鏈表頭。
3.哈希函數,最重要是散列,減小碰撞。
4.散列算法:除法散列。
0.全文檢索:是將存儲於數據庫中的整本書或整篇文章的任意內容信息查找出來的技術。能夠根據須要得到全文中有關章、節、段、句、詞的信息。也能夠進行統計和分析。
1.左模糊不走B+樹索引。
2.倒排索引:在輔助表中存儲了單詞和單詞自身在一個或多個文檔中所在位置的映射。經過關聯數組實現。
3.全文檢索的SQL語句:
SELECT * FROM 表名 WHERE MATCH(字段名) AGAINST (‘檢索的具體值‘)
1.行級鎖有如下兩種。
共享鎖:容許事務讀一行數據。
排它鎖:容許事務刪除或更新一行數據。如有其餘事務想得到排它鎖,必須等原來的事務釋放鎖。
2.鎖的相關表。information_schema架構下的表INNODB_TRX,INNODB_LOCKS,INNODB_LOCK_WAITS。
命令:SHOW ENGINE INNODB STATUS。
1.指的是經過多行版本控制的方式讀數據庫。若是讀取的行正在執行變動操做,這時不會等待鎖釋放。相反,INNODB引擎會去讀取行的一個快照數據。
之因此成爲非鎖定讀,是由於不須要等待訪問的行的鎖釋放。
2.在READ COMMITTED事務隔離級別下,對於快照數據,非一致性讀老是讀取被鎖定的行的最新一份快照數據。在REPEATABLE READ事務隔離級別下,對於快照數據,非一致性讀老是讀取事務開始時的行數據版本。
3.在事務的默認配置下,事務的隔離級別爲REPEATABLE READ模式。INNODB存儲引擎的SELECT操做,使用一致性非鎖定讀。
1.一致性鎖定讀,對數據庫的讀操做進行加鎖以保證數據邏輯的一致性。
好比如今有兩個線程,A線程讀時另B線程改變了數據,那麼在READ COMMITED隔離級別下,A線程第二次讀到的是最新的數據。
2.鎖定讀有兩種。SELECT ... FOR UPDATE和SELECT... LOCK IN SHARE MODE。
3.一致性鎖定讀,SELECT FOR UPDATE對讀取的行記錄加入一個X鎖(排它鎖),其餘事務不能對已鎖定的行加任何鎖。
而對於一致性非鎖定讀,即便讀取的行已經執行了SELECT FOR UPDATE,也是能夠讀取的。
4.SELECT...IN SHARE MODE對讀取的行記錄加上一個S鎖,其餘事務能夠向被鎖定的行加S鎖,可是若是是加X鎖,則會被阻塞。
髒讀:髒數據是指未提交的數據。髒讀是指在不一樣的事務下,當前事務能夠讀到另外事務未提交的數據。這顯然違反了數據庫的隔離性。
髒讀發生的事務隔離級別:READ UNCOMMITED。
不可重複讀:在一個事務內兩次讀到的數據不同。好比,A事務尚未結束,B事務對同一數據進行修改,因爲B事務的修改,那麼A事務兩次讀到的數據是不同的。違背了數據庫事務一致性的要求。
不可重複讀,讀到的是已經提交的數據。
不可重複讀,發生的隔離級別是READ COMMITTED。
ORACLE默認的隔離級別也是READ COMMITTED。
幻讀:A事務讀取了B事務已經提交的新增數據。
丟失更新,是指一個事務的更新操做會被另外一個事務的更新操做覆蓋。
1.死鎖是指兩個或兩個以上的事務,在執行過程當中,因爭奪資源而形成的一種互相等待的現象。
2.死鎖解決方法:超時機制。
3.死鎖檢測:等待圖。
1.爲何Mysql索引,使用的數據結構,必須有序?
由於順序讀遠遠快於離散讀。
爲何在B+樹中新增數據,也要保證有序?
有序才能更快地找到存儲的內容。
B+樹還能用於磁盤。。
2.爲何要用B+樹?
B+樹又"矮"又"胖",可以更快地查找到內容。
3.B+樹爲何要把數據全放在葉子節點上面呢?
節點存儲的內容是有限的,只存放指針可以使節點的高度更矮,可以更快地查找到內容。
4.聯合索引的最左匹配原則,究竟是什麼?
聯合索引的數據結構,是怎樣的?
5.爲何散列表(哈希表)數據放到一個鏈表中就能減小碰撞?
6.數據庫鎖,java的鎖,和操做系統的鎖,是否原理都是同樣的??
7.鎖是怎麼處理多個事務的? A事務開啓後未提交,B事務進行其餘操做,會有怎樣的結果?(一致性非鎖定讀)