今日頭條實習面試題解析

題目來源:https://www.nowcoder.com/discuss/79937?type=2&order=3&pos=20&page=1
1,資料庫的隔離級別:
read uncommitted
read committed
repeatable read(MySQL資料庫預設級別)
Serializable

√: 可能出現 ×: 不會出現

                                          髒讀              不可反覆讀	             幻讀

Read uncommitted √ √ √
Read committed × √ √
Repeatable read × × √
Serializable × × ×
2,各個級別存在什麼問題以及如何解決的？
對資料進行加鎖,悲觀,樂觀鎖(對這方面不太瞭解,希望瞭解的給小弟解說一下,謝謝)
3,Redis哪些資料結構？(是value可以為哪幾種資料型別嗎?)
String字串
List列表
Set集合
Hash雜湊
Zset有序集合
4,5均和Redis有關,技術有限,後期再補充
(題目:4.SortSet底層資料結構是什麼？
5.跳錶和B樹區別？)
6,B+和B樹的區別？
結構上

B樹中關鍵字集合分佈在整棵樹中，葉節點中不包含任何關鍵字資訊，而B+樹關鍵字集合分佈在葉子結點中，非葉節點只是葉子結點中關鍵字的索引；
B樹中任何一個關鍵字只出現在一個結點中，而B+樹中的關鍵字必須出現在葉節點中，也可能在非葉結點中重複出現；
效能上（也即為什麼說B+樹比B樹更適合實際應用中作業系統的檔案索引和資料庫索引？）

不同於B樹只適合隨機檢索，B+樹同時支援隨機檢索和順序檢索；
B+樹的磁碟讀寫代價更低。B+樹的內部結點並沒有指向關鍵字具體資訊的指標，其內部結點比B樹小，盤塊能容納的結點中關鍵字數量更多，一次性讀入記憶體中可以查詢的關鍵字也就越多，相對的，IO讀寫次數也就降低了。而IO讀寫次數是影響索引檢索效率的最大因素。
B+樹的查詢效率更加穩定。B樹搜尋有可能會在非葉子結點結束，越靠近根節點的記錄查詢時間越短，只要找到關鍵字即可確定記錄的存在，其效能等價於在關鍵字全集內做一次二分查詢。而在B+樹中，順序檢索比較明顯，隨機檢索時，任何關鍵字的查詢都必須走一條從根節點到葉節點的路，所有關鍵字的查詢路徑長度相同，導致每一個關鍵字的查詢效率相當。
（資料庫索引採用B+樹的主要原因是，）B-樹在提高了磁碟IO效能的同時並沒有解決元素遍歷的效率低下的問題。B+樹的葉子節點使用指標順序連線在一起，只要遍歷葉子節點就可以實現整棵樹的遍歷。而且在資料庫中基於範圍的查詢是非常頻繁的，而B樹不支援這樣的操作（或者說效率太低）。
7.資料庫InnoDB下如何加鎖？
在mysql 的 InnoDB引擎支援行鎖，與Oracle不同，mysql的行鎖是通過索引載入的，即是行鎖是加在索引響應的行上的，要是對應的SQL語句沒有走索引，則會全表掃描
行鎖則無法實現，取而代之的是表鎖。
表鎖：不會出現死鎖，發生鎖衝突機率高，併發低。
行鎖：會出現死鎖，發生鎖衝突機率低，併發高。
鎖衝突：例如說事務A將某幾行上鎖後，事務B又對其上鎖，鎖不能共存否則會出現鎖衝突。（但是共享鎖可以共存，共享鎖和排它鎖不能共存，排它鎖和排他鎖也不可以）
死鎖：例如說兩個事務，事務A鎖住了1_{5行，同時事務B鎖住了6}10行，此時事務A請求鎖住6_{10行，就會阻塞直到事務B施放6}10行的鎖，而隨後事務B又請求鎖住1_{5行，事務B也阻塞直到事務A釋放1}5行的鎖。死鎖發生時，會產生Deadlock錯誤。
鎖是對錶操作的，所以自然鎖住全表的表鎖就不會出現死鎖。
2.行鎖的型別
行鎖分 共享鎖 和 排它鎖。
共享鎖又稱：讀鎖。當一個事務對某幾行上讀鎖時，允許其他事務對這幾行進行讀操作，但不允許其進行寫操作，也不允許其他事務給這幾行上排它鎖，但允許上讀鎖。
排它鎖又稱：寫鎖。當一個事務對某幾個上寫鎖時，不允許其他事務寫，但允許讀。更不允許其他事務給這幾行上任何鎖。包括寫鎖。
89兩題資料庫語句分析,索引,不太熟悉,以後加強補充(題目:8.分析 delect from table where user_id=“1”；這句話怎麼加鎖的？
9.如果user_id使用單列索引，聯合索引，又是怎麼加鎖的？)
10,演算法題:

待續