Java面試題精講視訊112集（2020年大廠面試必備）

資料庫

1.索引的本質解析

資料庫--圖靈資料庫1.索引的本質解析2.Explain詳解與索引最佳實踐3.一條SQL在MySQL中是如何執行的4.Mysql索引優化實戰一5.Mysql索引優化實戰二6.Mysql鎖與事務隔離級别7. MVCC與BufferPool緩存機制2.java虛拟機JVM3.java記憶體模型JMM

二叉樹

資料結構：

https://www.cs.usfca.edu/~galles/visualization/Algorithms.html

元數有序時二叉樹會退變成連結清單

https://www.cs.usfca.edu/~galles/visualization/BST.html

紅黑樹（平衡二叉樹）

資料量特别大時，紅黑樹的高度會變的特别高，查找速度變低。

https://www.cs.usfca.edu/~galles/visualization/RedBlack.html

b-樹

b+樹

原始b+樹

b+樹從左到右是排好序的

mysq對B+樹做了優化，節點之間是雙向指向的及雙向清單，原始的b+樹樹單向的

存儲引擎索

聚集(聚簇)索引

InnoDB屬于聚集索引：索引和資料存儲在一起

MyLsam屬于非聚集索引：索引和資料不存儲在一起

聚集索引的查找資料打快于非聚集索引，聚集索引索引和資料在一起，找到索引及找到資料，而非聚集索引需要跨檔案查找，找到索引後還要到另一個檔案找資料

存儲引擎是針對表來說的

innodb存儲引擎索引實作解析

InnoDB存儲引擎的實作（生産中絕大多數使用）

問題

1.為什麼建議InnoDB表必須建主鍵

如果我們不指定主鍵，InnoDB是從所有列中找出此列每行資料都不同的一列作為主鍵，如果不存在這樣的列InnoDB會幫我們建立一個隐藏列作為主鍵。是以盡量我們自己來指定主鍵而不是讓資料庫幫我開指定。

2.使用整型的自增主鍵

主鍵比大小整型速度最快，整形比字元串(UUID)會快很多
B+樹每個葉子節點是從左到右自增的

hash對于B+數的缺點

1.哈希沖突

2.哈希不支援範圍查找

3.為什麼非主鍵索引結構葉子節點存儲的是主鍵值？

一緻性和節省存儲空間

InnoDB存儲引擎表對應的檔案

myisam存儲引擎索引實作解析

myLSAM存儲引擎的實作

myLSAM存儲引擎表對應的檔案

索引是怎麼支撐千萬級表的快速查找

mysql的底層索引有B+Tree和hash

一般都使用的是B+Tree

hash也可以做到很快的查找速度，但是不支援範圍查找，B-Tree也不很好的支援範圍查找

聯合索引底層結構

索引最左字首原理

2.Explain詳解與索引最佳實踐

Explain主要用來分析sql語句

在日常工作中，我們會有時會開慢查詢去記錄一些執行時間比較久的SQL語句，找出這些SQL語句并不意味着完事了，些時我們常常用到explain這個指令來檢視一個這些SQL語句的執行計劃，檢視該SQL語句有沒有使用上了索引，有沒有做全表掃描，這都可以通過explain指令來檢視。是以我們深入了解MySQL的基于開銷的優化器，還可以獲得很多可能被優化器考慮到的通路政策的細節，以及當運作SQL語句時哪種政策預計會被優化器采用。

Explain工具介紹使用EXPLAIN關鍵字可以模拟優化器執行SQL語句，分析你的查詢語句或是結構的性能瓶頸在 select 語句之前增加 explain 關鍵字，MySQL 會在查詢上設定一個标記，執行查詢會傳回執行計劃的資訊，而不是執行這條SQL 注意：如果 from 中包含子查詢，仍會執行該子查詢，将結果放入臨時表中

3.一條SQL在MySQL中是如何執行的

MySQL的内部元件結構

Server層主要包括連接配接器、查詢緩存、分析器、優化器、執行器等，涵蓋 MySQL 的大多數核心服務功能，以及所有的内置函數（如日期、時間、數學和加密函數等），所有跨存儲引擎的功能都在這一層實作，比如存儲過程、觸發器、視圖等。

Store層存儲引擎層負責資料的存儲和提取。其架構模式是插件式的，支援 InnoDB、MyISAM、Memory 等多個存儲引擎。現在最常用的存儲引擎是 InnoDB，它從 MySQL 5.5.5 版本開始成為了預設存儲引擎。也就是說如果我們在create table時不指定表的存儲引擎類型,預設會給你設定存儲引擎為InnoDB。

連接配接器我們知道由于MySQL是開源的，他有非常多種類的用戶端：navicat,mysql front,jdbc,SQLyog等非常豐富的用戶端,這些用戶端要向mysql發起通信都必須先跟Server端建立通信連接配接，而建立連接配接的工作就是有連接配接器完成的。

第一步，你會先連接配接到這個資料庫上，這時候接待你的就是連接配接器。連接配接器負責跟用戶端建立連接配接、擷取權限、維持和管理連接配接。連接配接指令一般是這麼寫的：

連接配接指令中的 mysql 是用戶端工具，用來跟服務端建立連接配接。在完成經典的 TCP 握手後，連接配接器就要開始認證你的身份，這個時候用的就是你輸入的使用者名和密碼。

1、如果使用者名或密碼不對，你就會收到一個"Access denied for user"的錯誤，然後用戶端程式結束執行。

2、如果使用者名密碼認證通過，連接配接器會到權限表裡面查出你擁有的權限。之後，這個連接配接裡面的權限判斷邏輯，都将依賴于此時讀到的權限。

這就意味着，一個使用者成功建立連接配接後，即使你用管理者賬号對這個使用者的權限做了修改，也不會影響已經存在連接配接的權限。修改完成後，隻有再建立的連接配接才會使用新的權限設定。使用者的權限表在系統表空間的mysql的user表中。

4.Mysql索引優化實戰一

優化準則：

sql查詢盡量單表操作，避免複雜操作，複雜的多表通過java代碼實作

建構複合索引優化

避免查詢索引失效

文檔：04-VIP-Mysql索引優化實戰一.note

連結：http://note.youdao.com/noteshare?id=0727c1f390616bb11986a975986093b3&sub=CEEC9C46957244058F7ADD6394E68E2D

聯合索引優化

in 和or資料量小的時候不走索引，資料量大的時候都會走索引。

通過聯合索引優化sql

一張表建的聯合索引盡量不要超過3個，聯合索引太多的還影響表中資料的插入和删除的效率。

如果是讀多寫少的場景可以多建些聯合索引(3-4個)，如果是寫多的場景聯合索引不要查過三個。

一張表的資料行數一般不超過千萬。

5.Mysql索引優化實戰二

文檔：05-VIP-Mysql索引優化實戰二.note

連結：http://note.youdao.com/noteshare?id=bd9b3d9a9e5764f6b63eb915b106dd39&sub=B5147BE69CBC46108B6DB24F9C055365

分頁查詢優化

很多時候我們業務系統實作分頁功能可能會用如下sql實作

表示從表 employees 中取出從 10001 行開始的 10 行記錄。看似隻查詢了 10 條記錄，實際這條 SQL 是先讀取 10010

條記錄，然後抛棄前 10000 條記錄，然後讀到後面 10 條想要的資料。是以要查詢一張大表比較靠後的資料，執行效率

是非常低的。

優化：

6.Mysql鎖與事務隔離級别

事務及其ACID屬性

事務是由一組SQL語句組成的邏輯處理單元,事務具有以下4個屬性,通常簡稱為事務的ACID屬性。

原子性(Atomicity) ：事務是一個原子操作單元,其對資料的修改,要麼全都執行,要麼全都不執行。

一緻性(Consistent) ：在事務開始和完成時,資料都必須保持一緻狀态。這意味着所有相關的資料規則都必須應用于事務的修改,以保持資料的完整性。

隔離性(Isolation) ：資料庫系統提供一定的隔離機制,保證事務在不受外部并發操作影響的“獨立”環境執行。這意味着事務處理過程中的中間狀态對外部是不可見的,反之亦然。

持久性(Durable) ：事務完成之後,它對于資料的修改是永久性的,即使出現系統故障也能夠保持。

并發事務處理帶來的問題

更新丢失(Lost Update)或髒寫

　　當兩個或多個事務選擇同一行，然後基于最初標明的值更新該行時，由于每個事務都不知道其他事務的存在，就會發生丢失更新問題–最後的更新覆寫了由其他事務所做的更新。

髒讀（Dirty Reads）

　　一個事務正在對一條記錄做修改，在這個事務完成并送出前，這條記錄的資料就處于不一緻的狀态；這時，另一個事務也來讀取同一條記錄，如果不加控制，第二個事務讀取了這些“髒”資料，并據此作進一步的處理，就會産生未送出的資料依賴關系。這種現象被形象的叫做“髒讀”。

　　一句話：事務A讀取到了事務B已經修改但尚未送出的資料，還在這個資料基礎上做了操作。此時，如果B事務復原，A讀取的資料無效，不符合一緻性要求。

不可重讀（Non-Repeatable Reads）

　　一個事務在讀取某些資料後的某個時間，再次讀取以前讀過的資料，卻發現其讀出的資料已經發生了改變、或某些記錄已經被删除了！這種現象就叫做“不可重複讀”。

　　一句話：事務A内部的相同查詢語句在不同時刻讀出的結果不一緻，不符合隔離性

幻讀（Phantom Reads）

　　一個事務按相同的查詢條件重新讀取以前檢索過的資料，卻發現其他事務插入了滿足其查詢條件的新資料，這種現象就稱為“幻讀”。

　　一句話：事務A讀取到了事務B送出的新增資料，不符合隔離性

Mysql預設的事務隔離級别是可重複讀，用Spring開發程式時，如果不設定隔離級别預設用Mysql設定的隔離級别，如果Spring設定了就用已經設定的隔離級别

鎖詳解

樂觀鎖

總是認為不會産生并發問題，每次去取資料的時候總認為不會有其他線程對資料進行修改，是以不會上鎖，但是在更新時會判斷其他線程在這之前有沒有對資料進行修改，一般會使用版本号機制或CAS操作實作。

version方式：一般是在資料表中加上一個資料版本号version字段，表示資料被修改的次數，當資料被修改時，version值會加一。當線程A要更新資料值時，在讀取資料的同時也會讀取version值，在送出更新時，若剛才讀取到的version值為目前資料庫中的version值相等時才更新，否則重試更新操作，直到更新成功。

核心SQL代碼：

update table set x=x+1, version=version+1 where id=#{id} and version=#{version};

CAS操作方式：即compare and swap 或者 compare and set，涉及到三個操作數，資料所在的記憶體值，預期值，新值。當需要更新時，判斷目前記憶體值與之前取到的值是否相等，若相等，則用新值更新，若失敗則重試，一般情況下是一個自旋操作，即不斷的重試。

悲觀鎖

總是假設最壞的情況，每次取資料時都認為其他線程會修改，是以都會加鎖（讀鎖、寫鎖、行鎖等），當其他線程想要通路資料時，都需要阻塞挂起。可以依靠資料庫實作，如行鎖、讀鎖和寫鎖等，都是在操作之前加鎖，在Java中，synchronized的思想也是悲觀鎖。

表鎖

每次操作鎖住整張表。開銷小，加鎖快；不會出現死鎖；鎖定粒度大，發生鎖沖突的機率最高，并發度最低；一般用在整表資料遷

行鎖

每次操作鎖住一行資料。開銷大，加鎖慢；會出現死鎖；鎖定粒度最小，發生鎖沖突的機率最低，并發度最高。

MYISAM不支援事務，隻支援表鎖

InnoDB與MYISAM的最大不同有兩點：

InnoDB支援事務（TRANSACTION）
InnoDB支援行級鎖

可重複讀

（1）打開一個用戶端A，并設定目前事務模式為repeatable read，查詢表account的所有記錄

set tx_isolation=‘repeatable-read’;

（2）在用戶端A的事務送出之前，打開另一個用戶端B，更新表account并送出

（3）在用戶端A查詢表account的所有記錄，與步驟（1）查詢結果一緻，沒有出現不可重複讀的問題

（4）更新資料時不要查出來再做邏輯讓後更新資料庫資料，而是直接使用 upate語句實時更新資料，這樣balance才是資料庫真實的值。在用戶端A，接着執行update account set balance = balance - 50 where id = 1，balance沒有變成400-50=350，lilei的balance值用的是步驟2中的350來算的，是以是300，資料的一緻性倒是沒有被破壞。可重複讀的隔離級别下使用了MVCC(multi-version concurrency control)機制，select操作不會更新版本号，是快照讀（曆史版本）；insert、update和delete會更新版本号，是目前讀（目前版本）。

（5）重新打開用戶端B，插入一條新資料後送出

（6）在用戶端A查詢表account的所有記錄，沒有查出新增資料，是以沒有出現幻讀

索引失效的弊端：

結論

Innodb存儲引擎由于實作了行級鎖定，雖然在鎖定機制的實作方面所帶來的性能損耗可能比表級鎖定會要更高一下，但是在整體并發處理能力方面要遠遠優于MYISAM的表級鎖定的。當系統并發量高的時候，Innodb的整體性能和MYISAM相比就會有比較明顯的優勢了。

但是，Innodb的行級鎖定同樣也有其脆弱的一面，當我們使用不當的時候，可能會讓Innodb的整體性能表現不僅不能比MYISAM高，甚至可能會更差。

7. MVCC與BufferPool緩存機制

MVCC

MVCC機制：所有資料在mysql内部有一個undo.log日志，及und日志版本鍊，在事務中第一次執行查詢語句的時候會生成read view 一緻性試圖，這個事務中所有的查詢語句，根據read view去undo日志中比對找到對應的資料。select操作不會更新read view版本号，是快照讀（曆史版本）；insert、update和delete會更新版本号，是目前讀（目前版本）。

每個事務裡面都有自己的rea-view。

buffer pool 是為了提高效率。

2.java虛拟機JVM

jdk體系和jvm架構講解

JDK體系結構

JVM整體結構