數據庫方面-----面試真題彙總（含答案）

全部是各大廠的數據方面的真是面試題

面試題1. MySQL如何在RR隔離級別下避免幻讀問題：Next-Key鎖（代表行鎖和GAP間隙鎖的合併）?

• 其實是通過間隙鎖和行鎖共同來解決的幻讀問題，在RR隔離級別下，行鎖的原理，如果有一個事務A在進行update一個主鍵ID爲2的數據，那麼此時如果事務B過來進行插入ID爲2的數據的話那麼此時的行鎖就保證了事務B必須阻塞等待事務Acommit之後，事務B的操作纔會生效
• 而下面的間隙鎖就是數據庫中只有teacher_id爲5和30，中間這部分就是間隙鎖要加鎖的範圍。update的teacher_id=20是在(5，30]區間，即使沒有修改任何數據，Innodb也會在這個區間加gap鎖，而其它區間不會影響，事務C正常插入。

如果使用的是沒有索引的字段，比如update class_teacher set teacher_id=7 where class_name=‘初三八班（即使沒有匹配到任何數據）’,那麼會給全表加入gap鎖。同時，它不能像上文中行鎖一樣經過MySQL Server過濾自動解除不滿足條件的鎖，因爲沒有索引，則這些字段也就沒有排序，也就沒有區間。除非該事務提交，否則其它事務無法插入任何數據

總結：行鎖防止別的事務修改或刪除，GAP鎖防止別的事務新增，行鎖和GAP鎖結合形成的的Next-Key鎖共同解決了RR級別在寫數據時的幻讀問題

面試題2. MySQL的引擎講一下，有什麼區別，使用場景呢？

首先MySQL的引擎分爲innodb和myisam 兩種，而且默認使用的是innodb的引擎。

兩者的區別：
2. 事務方面：innodb是事務安全的，而myisam非事務安全的
3. 鎖機制方面：innodb是行級鎖的，而myisam是表級鎖的
4. 存儲方面：innodb是聚集索引，也就是說他的索引和數據都是在一起的，而myisam是非聚集索引，也就是說他的索引和數據文件是分開的。
5. 事務外鍵：mysiam表不支持外鍵，而InnoDB支持
6. 查詢方面：當進行select count（*）from table 的時候，mysiam是直接讀取除本身就保存有的變量，而innodb則需要進行全表掃描，效率相對比較低，但是如果在使用innodb的時候加上where條件查詢的話就會和myisam的操作一樣
兩者的使用場景：
7. MyISAM適合：(1)做很多count 的計算；(2)插入不頻繁，查詢非常頻繁；(3)沒有事務。
8. InnoDB適合：(1)可靠性要求比較高，或者要求事務；(2)表更新和查詢都相當的頻繁，並且行鎖定的機會比較大的情況

自己的一些總結：

• 首先Myisam使用的是非聚集索引（也就是物理數據和索引是分開存儲的，索引只存儲在非葉子節點，只有真是的數據庫的行數據的物理地址才存儲在最下層的葉子節點上），所以底層使用的是B+tree來進行實現的底層
• 而Innodb使用的是聚集索引（也就是物理數據和索引是存儲在同一個葉子節點上的），但是底層使用的也是B+tree來進行實現的底層的存儲。

面試題3. mysql的索引講一下，一級和二級索引的區別，什麼時候可以不用查一級索引

• 首先一級索引其實就是當你的MySQL中有主鍵的時候，該主鍵就是一級索引，二級索引就是可以根據我們自己需要的字段可以去建立二級索引。

爲什麼索引能提高查詢效率？

先看一下索引的結構：

上面其實就是一個葉子

其實MySQL中B+的每一個節點就是對應一頁，站在的數據結構的角度來看，其實節點就是頁爲單位，但是每一個頁中的數據又含有了很多條數據記錄，這個記錄對應的就是數據庫中按照主鍵進行排列的順序

面試題4. MySQL的事務性質怎麼實現的，其中的持久性和隔離性說一下。默認級別是哪個，通過什麼實現的

MySQL的事務性質怎麼實現的？

• 首先MySQL的事務是有四個特性A（原子性）、C（一致性）、I（隔離性）D（持久性），而原子性、一致性、持久性是由數據庫中的redo log 和undo log來完成的，而隔離性是通過數據的加鎖來進行實現的
• redo log用來保證事務的持久性，其實就是將該事務的所有日誌寫入到重做日誌文件進行持久化，待事務的commit操作完成纔算完成。
• undo log其實就是爲了事務的回滾而生的，因爲在提交事務的時候，有可能會失敗，這時就需要undo log來進行回滾事件。

MySQL的默認隔離級別是RR級別（repeat read重複讀）

面試題5. MySQL索引的實現，innodb的索引，b+樹索引是怎麼實現的，爲什麼用b+樹做索引節點，一個節點存了多少數據，怎麼規定大小，與磁盤頁對應。

面試題5. MySQL的事務隔離級別，分別解決什麼問題。

（1）read uncommitted（讀取未提交數據）
出現的情景就是，當有一個事務A對數據庫進行插入了一條數據（插入之後的數據爲11條，插入之前爲10條），此時另外有一個事務B先查詢了數據有11條（因爲到這的時候A事務並沒有提交），之後事務A才提交事務，這時事務B又去查詢數據庫發現變成了10條。此時的問題：事務B心想，我剛剛查的數據是11條啊，爲啥這次又查詢的數據又變成10條了？，肯定是我讀錯了。。。

• 結論：我們將事務隔離級別設置爲read uncommitted，即便是事務沒有commit，但是我們仍然能讀到未提交的數據，這是所有隔離級別中最低的一種
• 出現的問題：只要一個事務A開啓之後，無論有沒有提交，不管做的修改和添加的任何操作，在其他的事務中都能讀取到事務A的操作，這就是最低級的一個隔離級別，所以會出現髒讀。

（2）read committed（可以讀取其他事務提交的數據）—大多數數據庫默認的隔離級別。這個級別其實是進一步改善第一種的隔離級別，
情景爲；當一個事務A開始之後，執行把小明的錢增加20（沒有增加前是100），此時事務A查詢到的小明的錢已經變成了120（到這的時候事務A還沒有提交事務），此時事務B過來去查詢小明的錢還是100，但是這個時候事務A纔去提交事務，但是事務B再去查詢發現小明的錢還是100，這個事務B就納悶了，剛剛我查詢的還是120的，爲啥突然就變成100了，兩次查詢的結果不一致，出現的問題就是不可重複讀。。

• 結論：當我們將當前會話的隔離級別設置爲read committed的時候，當前會話只能讀取到其他事務提交的數據，未提交的數據讀不到。
• 出現的問題：當我們在一個回話B事務中，讀取到兩次不同的結果，這就造成了不可重複讀，這就造成了不可重複讀的問題，繼續解決。

（3）repeatable read（可重讀）—MySQL默認的隔離級別
情景就是：現在我在事務A中開啓可重複讀的級別事務，並添加了一條數據（本來是10條數據），事務A先查詢數據爲11條（這裏事務A先檢驗一下添加成工了），然後在事務B中查詢到的數據卻爲10條（此時B不知道A已經插入數據且成功了），但是此時事務B想插入同一條數據（也就是第11條數據），但是卻報錯了，說已經不能重複插入數據，然後事務B開始想，我明明看到的是隻有10條數據啊，爲啥不讓我插第11條，他心想難到是我看錯了。（所以這就是幻讀的問題。，。）

• 結論：當我們將當前會話的隔離級別設置爲repeatable read的時候，當前會話可以重複讀，就是每次讀取的結果集都相同，而不管其他事務有沒有提交。
• 出現的問題：事務A添加了一條數據，並且成功此時事務A驗證的時候爲11條，還沒有提交，事務B過來查詢發現數據還是10條，然後事務B去插入同樣的第11條數據，並沒有成功（提示說不能重複插入第11條數據，懷疑自己是不是看錯了，幻讀問題。。）

（4） serializable（串行化）

只要是開啓了最高隔離級別的串行化，所有的事務A操作沒有完成之前，所有的其他事務想要操作的同一個表，都需要排隊進行阻塞，這就是串行化的場景

• 結論：當我們將當前會話的隔離級別設置爲serializable的時候，其他會話對該表的寫操作將被掛起。可以看到，這是隔離級別中最嚴格的，但是這樣做勢必對性能造成影響。所以在實際的選用上，我們要根據當前具體的情況選用合適的。
• 出現的問題：太完美了，沒有一點問題，就是效率低。

面試題6. mysql中索引的類型和底層數據結構（需要在看一下）

1. MySQL的索引類型常見的有B-Tree索引、B+Tree索引、Hash索引三種主流的索引類型

• 主鍵索引 （其實就是一張表的主鍵，主鍵不能爲空且唯一）
• 唯一索引 （唯一索引，就是索引的字段必須唯一，但是可以爲空）
• 普通索引 （這個就是普通的字段，沒有什麼限制）
• 全文索引 （其實就是有點類似ES中的倒排索引 的全文檢索，但是目前只支持英文，還不支持中文的全文索引）innodb 和Myisam都支持
• 組合索引 （用多個列組合構建的索引，這多個列中的值不允許有空值）

2. 不同的索引引擎的實現類型：

• Innodb
• Myisam
• memory（內存存儲引擎），在用hash縮影的時候，哈希索引用索引列的值計算該值的hashCode，然後在hashCode相應的位置存執該值所在行數據的物理位置

3. 三種索引的底層結構：

• B-Tree索引：其實就是一個B樹，但是他的一個特點就是他的索引和數據都是在一個節點上的，這樣的缺點就是，由於操作系統中的每次進行的IO的大小都是固定的頁，也就是每次操作系統IO的大小隻能是一頁一頁的進行IO，但是由於B-Tree的索引和數據都是在一起的（稱爲一個節點），但是每次操作系統IO的頁的大小又是固定的，如果節點太大的話，那麼一次IO取出來的節點就越少，IO次數就增多，效率就低了
• 所以就有了B+Tree樹的改進，他的底層就是索引和數據是分開的，也就是B+Tree的所有葉子都是數據，非葉子節點都是索引，這樣的話就彌補了B-Tree的缺點，也就是每次IO的頁的大小不變，但是IO的節點大小變小了（因爲只有索引沒有數據），所以IO的次數變小了，效率就高了
• Hash索引：底層實現的數據結構其實就是對數據進行Hash運算，先對拿到的數據進行得到hash值（數據過多會出現hash碰撞），然後再去根據hash值去拿到需要的數據指針地址，然後拿到數據。雖然如果沒有出現hash碰撞的時候效率很高，但是缺點就是不能進行範圍查詢。

面試題7. 數據庫設計的範式知道嗎？第一範式、第二範式和第三範式的區別，說的具體一些

1. 第一範式：我理解的第一範式其實就是數據庫的列不能再繼續分，強調的是列的原子性
2. 第二範式：首先是必須建立在第一範式基礎上的，然後此外必須滿足兩個條件，第一個是必須有主鍵，第二個是沒有包含在主鍵中的列必須完全依賴於主鍵，而不能只依賴於主鍵的一部分。其實就是消除部分依賴
3. 第三範式：滿足第二範式下，並且表中的列不存在對非主鍵列的傳遞依賴。就是不能字段A---->完全依賴於主鍵，但是字段B---->又完全依賴字段A，其實字段B和主鍵並沒有太大關係，這就是依賴傳遞

面試題8. MySQL範式和反範式的區別以及彼此的優缺點

• 範式的優點就是
  1)範式化的數據庫更新起來更加快;

  2)範式化之後,只有很少的重複數據,只需要修改更少的數據;

  3)範式化的表更小,可以在內存中執行;

  4)很少的冗餘數據,在查詢的時候需要更少的distinct或者group by語句。

• 範式的缺點：

範式化的表,在查詢的時候經常需要很多的關聯,因爲單獨一個表內不存在冗餘和重複數據。這導致,稍微複雜一些的查詢語句在查詢範式的schema上都可能需要較多次的關聯。這會增加讓查詢的代價,也可能使一些索引策略無效。因爲範式化將列存放在不同的表中,而這些列在一個表中本可以屬於同一個索引。

• 反範式的優點：
  1)可以避免關聯,因爲所有的數據幾乎都可以在一張表上顯示;

  2)可以設計有效的索引;

  3)可以根據業務適當的做出改變

• 反範式的缺點：
  3)表格內的冗餘較多,刪除數據時候會造成表有些有用的信息丟失。

面試題9. 查詢中哪些情況不會使用索引？

索引失效的幾種情況：https://blog.csdn.net/qq_36520235/article/details/82931885

面試題10. 說一下數據庫的讀寫分離

面試題11. MySQL主從複製瞭解嗎

1. 主從複製其實就是爲了減輕數據庫的壓力，然後以主從複製爲基礎，然後實現數據庫的讀寫分離來提升數據庫的併發負載壓力。
2. 其實就是主庫新建一個IO線程，把數據的一些改變記錄到二進制binlog日誌中，然後salve服務器會在一定時間間隔內對master二進制日誌進行探測其是否發生改變，
3. 如果主二進制日誌中有發生改變，則從服務器開始一個I/OThread請求master二進制事件（binlog二進制文件），同時主節點爲每個I/O線程啓動一個dump線程，用於向其發送二進制事件，並保存至從節點本地的中繼日誌中，從節點將啓動SQL線程從中繼日誌中讀取二進制日誌，在本地重放，使得其數據和主節點的保持一致，最後I/OThread和SQLThread將進入睡眠狀態，等待下一次被喚醒。如果發生改變，則開始一個I/OThread請求master二進制事件，同時主節點爲每個I/O線程啓動一個dump線程，用於向其發送二進制事件，並保存至從節點本地的中繼日誌中，從節點將啓動SQL線程從中繼日誌中讀取二進制日誌，在本地重放，使得其數據和主節點的保持一致，最後I/OThread和SQLThread將進入睡眠狀態，等待下一次被喚醒。
   

面試題12. 分庫分表知道嗎

面試題13. 多表查詢怎麼優化

1. 我能想到的第一條就是不要使用子查詢進行查詢多表的SQL
2. 可以只使用where的條件進行關聯多表，不使用join來進行多表關聯
3. 開啓數據庫的緩存，然後把多表查詢都拆分爲單個的查詢

面試題14. MySQL如何在RR隔離級別下避免幻讀問題：間隙鎖

面試題15. B+樹和紅黑樹的區別、B+樹和B樹的區別？

B+樹和B樹的區別：

1. 存儲上：B樹在葉子節點存儲的有索引和數據都在一起，而B+樹是隻在葉子節點上存儲的有數據，非葉子節點上只存儲的有索引，所以B+樹的性能比較穩定，每次查詢都必須查詢到葉子節點才能取到數據，而B+則不穩定有時候好的情況直接根節點就取到數據，壞的情況會在葉子節點上才能查到數據。
2. 結構上：B樹的葉子節點（也就是最下層的葉子節點的兄弟節點之間沒有數據之間的聯繫），但是B+樹在最下層的葉子節點上都是用鏈表的結構進行連接的，可以方便範圍查詢，而B樹則是一次一次的進行中序遍歷查詢範圍起始節點和末尾節點
3. 查詢性能：因爲B+ 樹的非葉子節點不存儲數據，所以每次IO的數據會比較多，因爲每次IO的最小單位的頁的大小是固定的，所以每次查詢出來的索引值就比較多（因爲只有索引值沒有數據，數據也是需要佔用IO的大小的），而B樹每次IO頁的節點不僅有索引的值，還有數據，因爲IO的頁的大小固定，所以查詢的節點就少。

面試題16. mysql緩存瞭解嗎

面試題17. 事務1開啓事務，查詢一個表沒有數據，事務2新插一條數據，並且提交，事務2再次查詢是否有數據，事務1有數據嗎？爲什麼，講一下undo log，查詢會有undo log嗎？

• 再次查詢事務2能查到數據，而且事務1 也有數據。原因是：因爲每個事務都是互相隔離的，當事務2提交了事務之後，其實事務2所做的操作在事務1中，也都是同樣生效的。
• undo log其實就是爲了滿足事務的原子性，在操作任何數據之前，首先將數據備份到一個地方（這個存儲數據備份的地方稱爲UndoLog）。然後進行數據的修改。如果出現了錯誤或者用戶執行了ROLLBACK語句，系統可以利用Undo Log中的備份將數據恢復到事務開始之前的狀態
• 爲了保證持久性，必須將數據在事務提交前寫到磁盤。只要事務成功提交，數據必然已經持久化。
  Undo log必須先於數據持久化到磁盤。如果在G,H之間系統崩潰，undo log是完整的， 可以用來回滾事務

undo log其實就是爲了保證事務的原子性，當一個事務開始時會先記錄一下，然後如果中間事務出現異常的話，可以利用undo log 來進行把該事務回滾到最初的狀態

redo log其實簡單來說就是對新的數據進行的備份，把一些已經進行commit的事務重做一遍。對於沒有commit的事務，則進行處理，如果數據庫宕機了可以利用redo log來保證新數據的不丟失。

面試題18. MYSQL數據庫使用中什麼情況下會死鎖

下面列舉一下常出現的三種死鎖情景：

1. 有一個用戶A訪問表A，已經鎖住了A表，但是此時A又要去查詢B表：同時用戶B查詢B表，而且也已經鎖住了B表，此時B表也想去查詢A表，由於此時A表已經被用戶A鎖，B表也已經用戶B鎖住，所以就會造成死鎖。
2. 用戶A查詢一條紀錄，然後修改該條紀錄；這時用戶B修改該條紀錄，這時用戶A的事務裏鎖的性質由查詢的共享鎖企圖上升到獨佔鎖，而用戶B裏的獨佔鎖由於A 有共享鎖存在所以必須等A釋放掉共享鎖，而A由於B的獨佔鎖而無法上升的獨佔鎖也就不可能釋放共享鎖，於是出現了死鎖。這種死鎖比較隱蔽，但在稍大點的項 目中經常發生。如在某項目中，頁面上的按鈕點擊後，沒有使按鈕立刻失效，使得用戶會多次快速點擊同一按鈕，這樣同一段代碼對數據庫同一條記錄進行多次操 作，很容易就出現這種死鎖的情況。
3. 如果在事務中執行了一條不滿足條件的update語句，則執行全表掃描，把行級鎖上升爲表級鎖，多個這樣的事務執行後，就很容易產生死鎖和阻塞。類似的情 況還有當表中的數據量非常龐大而索引建的過少或不合適的時候，使得經常發生全表掃描，最終應用系統會越來越慢，最終發生阻塞或死鎖

面試題19. 說一下數據庫中的分佈式事務的2PC（二階提交協議）和3PC（三階提交協議）？

https://www.hollischuang.com/archives/681

面試題20. 說一下怎麼用原生的JDBC訪問數據庫？

1. 第一步首先是加載jdbc的驅動程序
2. 然後就可以從負責管理jdbc驅動的管理類DriverManager中獲取數據庫的實例連接對象DriverManager.getConnection（）來進行獲取，拿到的是一個Connection對象實例
3. 接着是使用Connection對象來獲取一個Statement對象實例，或者是PreparedStatement對象（這裏有對SQL預編譯功能和防止注入SQL功能）
4. 然後是對SQL語句的執行，返回的是一個Result對象結果集
5. 然後依次關閉數據庫的連接。

面試題21. 說一下mybatis的一級緩存和二級緩衝的原理？

一級緩存簡要概述： 首先一級緩存是mybatis中默認開啓的，而且是隻作用在SqlSession對象這個作用域中，然後SqlSession會把這個任務交給Executor執行器來去執行這個SQL語句，而緩存信息就維護在這個Executor接口中，而這個接口的實現者就是PerpetualCache這個類來通過一個大的Map來去保存這個緩存中的數據。

• 在我們執行了(update()、delete()、insert())這幾個操作的時候，那麼就都會清空PerpetualCache對象的數據，但是這個PerpetualCache緩存對象還是可以繼續使用的
  
  

一級緩存的流程前提準備：

1. 在看下面的流程的時候，必須先知道這個維護緩存的這個大Map是怎麼來進行保存已緩存的數據的。
2. 在對於某個查詢，根據statementId（MyBatis而言，你要使用它，必須需要一個statementId，它代表着你將執行什麼樣的Sql）,params（這個就是你傳入的參數）,rowBounds（它通過rowBounds.offset和rowBounds.limit來過濾查詢出來的結果集，這種分頁功能是基於查詢結果的再過濾，而不是進行數據庫的物理分頁）來構建一個key值，根據這個key值去緩存Cache中取出對應的key值存儲的緩存結果，其實就是通過一個createCacheKey（）方法，然後返回一個CacheKey 類型的key來作爲map的key，value就是查詢的數據值。

一級緩存的流程：

1. 其實就是先從SqlSession中去獲取這個參數（這個參數就是statementId + rowBounds + 傳遞給JDBC的SQL + 傳遞給JDBC的參數值），通過這幾個值生成一個CacheKey的key
2. 然後會通過這個key來去這個大的緩存Map中去看是不是有值，如果有直接就返回給用戶了，不用直接再去和MySQL中去拿數據了
3. 如果這個key不存在的話，那麼就會從MySQL中去獲取數據，然後會把根據這個不存在的key重新緩存到這個大的map中，以便下次在進行請求。
4. 那麼你該會想了 ，如果一直放到這個map中，那麼這個數據肯定會越來越多啊，多到這個map都放不下，那該怎麼辦？
5. 首先1. SqlSession的生存時間也不長。2. 其次就是對於這個SqlSession對象來說，如果每當執行update操作（update、insert、delete），都會對這個SqlSession的一級緩存進行清理。3. 當然你也可以進行手動的關閉這個SqlSession對象。這三點都能保證這個大Map不會無限變大。

二級緩存概述：

• 二級緩存是Application應用級別的緩存，它的是生命週期很長，跟Application的聲明週期一樣，也就是說它的作用範圍是整個Application應用

• 由一級緩存可知一個SqlSession對象會使用一個Executor對象來完成會話操作，MyBatis的二級緩存機制的關鍵就是對這個Executor對象做文章

• 如果用戶在這裏配置了開啓二級緩存的話（cacheEnabled=true），那麼MyBatis在爲SqlSession對象創建Executor對象時，會對Executor對象加上一個裝飾者：CachingExecutor，

• 這時SqlSession使用CachingExecutor對象來完成操作請求。CachingExecutor對於查詢請求，會先判斷該查詢請求在Application級別的二級緩存中是否有緩存結果，如果有查詢結果，則直接返回緩存結果；如果緩存中沒有，再交給真正的Executor對象來完成查詢操作，之後CachingExecutor會將真正Executor返回的查詢結果放置到緩存中，然後在返回給用戶。

注意：如果你的MyBatis使用了二級緩存，並且你的Mapper和select語句也配置使用了二級緩存，那麼在執行select查詢的時候，MyBatis會先從二級緩存中取輸入，其次纔是一級緩存，即MyBatis查詢數據的順序是：

           二級緩存    ———> 一級緩存——> 數據庫

面試題22. 主鍵索引 和普通索引 (輔助索引) 的區別？

• 首先在MyISAM中，由於是非聚集索引，所以主鍵索引和輔助索引沒有本質上的區別，只是主索引要求key是唯一的，而輔助索引的key可以重複（比如說輔助索引加在的是name字段上）
  
• 在InnoDB數據庫引擎中，InnoDB的所有輔助索引都引用主鍵作爲data域，聚集索引（主鍵索引）這種實現方式使得按主鍵的搜索十分高效，但是輔助索引搜索需要檢索兩遍索引：首先檢索輔助索引獲得主鍵，然後用主鍵到主索引中檢索獲得記錄，但是有一點需要注意，就是如果走的是輔助索引的話，是需要通過主鍵索引再去搜索一下的，但是如果走的是主鍵索引的話，那麼就只需要搜索一次就可以了，因爲通過輔助索引查詢到的知識主鍵的ID然後會再去通過主鍵ID去搜索一次
  

面試題23. 說一下爲什麼使用B+，B+有什麼優點（這裏可以延伸爲什麼使用B+不用別的，可以從二叉樹—>平衡二叉樹（AVL）—>B Tree(多路平衡查找樹）—>B+ Tree）？

自己總結的詳細講解文章：https://blog.csdn.net/qq_36520235/article/details/94317993

B+樹的優點：

1. 單次請求涉及的磁盤IO次數少（出度d大，且非葉子節點不包含表數據，樹的高度小）；
2. 查詢效率穩定（任何關鍵字的查詢必須走從根結點到葉子結點，查詢路徑長度相同）；
3. 遍歷效率高（從符合條件的某個葉子節點開始遍歷即可）；

B+樹的缺點：

1. B+樹最大的性能問題在於會產生大量的隨機IO，主要存在以下兩種情況：
2. 主鍵不是有序遞增的，導致每次插入數據產生大量的數據遷移和空間碎片；
3. 即使主鍵是有序遞增的，大量寫請求的分佈仍是隨機的；

面試題24.說一下Innodb底層是如何實現的MVCC的？

這裏有大佬的總結：Innodb底層是如何實現MVCC的？

面試題25. MySQL InnoDB存儲引擎中的MVCC解決了什麼問題，能說下MVCC的實現原理麼

面試題26. MySQL刪除表操作（delete、truncate、drop的區別）

面試題27. 說一下MySQL查詢過程流程解析？

圖片是來自：https://blog.csdn.net/z_ryan/article/details/82262761

這個是MySQL的整個查詢的流程，雖然不怎麼問，但是瞭解之後，會對MySQL的認知有進一步的加深。

1、客戶端同數據庫服務層建立TCP連接。
2、客戶端向MySQL服務器發送一條查詢請求。
3、連接線程接收到SQL語句之後，將語句交給SQL語句解析模塊進行語法分析和語義分析。
4、先看查詢緩存中是否有結果，如果有結果可以直接返回給客戶端。
5、如果查詢緩存中沒有結果，就需要真的查詢數據庫引擎層了，於是發給SQL優化器，進行查詢的優化，生成相應的執行計劃。
6、MySQL根據執行計劃，調用存儲引擎的API來執行查詢
7、使用存儲引擎查詢時，先打開表，如果需要的話獲取相應的鎖。 查詢緩存頁中有沒有相應的數據，如果有則可以直接返回，如果沒有就要從磁盤上去讀取。
8、當在磁盤中找到相應的數據之後，則會加載到緩存中來，從而使得後面的查詢更加高效，由於內存有限，多采用變通的LRU表來管理緩存頁，保證緩存的都是經常訪問的數據。
9、最後，獲取數據後返回給客戶端，關閉連接，釋放連接線程。

都來自牛客網別人的真實面試中的問題，在此真誠的感謝各位分享的大佬們