一、MySQL架構相關

問題1：畫出 MySQL 架構圖

答：和其它數據庫相比，MySQL有點與眾不同，它的架構可以在多種不同場景中應用并發揮良好作用。主要體現在存儲引擎的架構上，插件式的存儲引擎架構將查詢處理和其它的系統任務以及數據的存儲提取相分離。這種架構可以根據業務的需求和實際需要選擇合適的存儲引擎。

連接層：最上層是一些客戶端和連接服務。主要完成一些類似于連接處理、授權認證、及相關的安全方案。在該層上引入了線程池的概念，為通過認證安全接入的客戶端提供線程。同樣在該層上可以實現基于SSL的安全鏈接。服務器也會為安全接入的每個客戶端驗證它所具有的操作權限。

服務層：第二層服務層，主要完成大部分的核心服務功能， 包括查詢解析、分析、優化、緩存、以及所有的內置函數，所有跨存儲引擎的功能也都在這一層實現，包括觸發器、存儲過程、視圖等

引擎層：第三層存儲引擎層，存儲引擎真正的負責了MySQL中數據的存儲和提取，服務器通過API與存儲引擎進行通信。不同的存儲引擎具有的功能不同，這樣我們可以根據自己的實際需要進行選取

存儲層：第四層為數據存儲層，主要是將數據存儲在運行于該設備的文件系統之上，并完成與存儲引擎的交互

問題2：MySQL的查詢過程 (一條sql語句在MySQL中如何執行)?

答：客戶端請求 ---> 連接器(驗證用戶身份，給予權限) ---> 查詢緩存(存在緩存則直接返回，不存在則執行后續操作) ---> 分析器(對SQL進行詞法分析和語法分析操作) ---> 優化器(主要對執行的sql優化選擇最優的執行方案方法) ---> 執行器(執行時會先看用戶是否有執行權限，有才去使用這個引擎提供的接口) ---> 去引擎層獲取數據返回(如果開啟查詢緩存則會緩存查詢結果)

存儲引擎是MySQL的組件，用于處理不同表類型的SQL操作。不同的存儲引擎提供不同的存儲機制、索引技巧、鎖定水平等功能，使用不同的存儲引擎，還可以獲得特定的功能。使用哪一種引擎可以靈活選擇，一個數據庫中多個表可以使用不同引擎以滿足各種性和實際需求，使用合適的存儲引擎，將會提高整個數據庫的性能。MySQL服務器使用可插拔的存儲引擎體系結構，可以從運行中的 MySQL 服務器加載或卸載存儲引擎 。

二、存儲引擎相關

問題3：說說MySQL有哪些存儲引擎?都有哪些區別?

答：常見的存儲引擎就 InnoDB、MyISAM、Memory、NDB。InnoDB 現在是 MySQL 默認的存儲引擎，支持事務、行級鎖定和外鍵，他們的區別如下:

1、InnoDB 支持事務，MyISAM 不支持事務。這是 MySQL 將默認存儲引擎從 MyISAM 變成 InnoDB 的重要原因之一;

2、InnoDB 支持外鍵，而 MyISAM 不支持。對一個包含外鍵的 InnoDB 表轉為 MYISAM 會失敗;

3、InnoDB 是聚簇索引，MyISAM 是非聚簇索引。聚簇索引的文件存放在主鍵索引的葉子節點上，因此 InnoDB 必須要有主鍵，通過主鍵索引效率很高。但是輔助索引需要兩次查詢，先查詢到主鍵，然后再通過主鍵查詢到數據。因此，主鍵不應該過大，因為主鍵太大，其他索引也都會很大。而 MyISAM 是非聚集索引，數據文件是分離的，索引保存的是數據文件的指針。主鍵索引和輔助索引是獨立的。

4、InnoDB 不保存表的具體行數，執行select count(*) from table 時需要全表掃描。而 MyISAM 用一個變量保存了整個表的行數，執行上述語句時只需要讀出該變量即可，速度很快;

5、InnoDB 最小的鎖粒度是行鎖，MyISAM 最小的鎖粒度是表鎖。一個更新語句會鎖住整張表，導致其他查詢和更新都會被阻塞，因此并發訪問受限。這也是 MySQL 將默認存儲引擎從 MyISAM 變成 InnoDB 的重要原因之一;

對比項MyISAMInnoDB主外鍵不支持支持事務不支持支持行表鎖表鎖，即使操作一條記錄也會鎖住整個表，不適合高并發的操作行鎖,操作時只鎖某一行，不對其它行有影響，適合高并發的操作緩存只緩存索引，不緩存真實數據不僅緩存索引還要緩存真實數據，對內存要求較高，而且內存大小對性能有決定性的影響表空間小大關注點性能事務默認安裝

問題4：一張表，里面有ID自增主鍵，當insert了17條記錄之后，刪除了第15,16,17條記錄，再把Mysql重啟，再insert一條記錄，這條記錄的ID是18還是15 ?

答：如果表的類型是MyISAM，那么是18。因為MyISAM表會把自增主鍵的最大ID 記錄到數據文件中，重啟MySQL自增主鍵的最大ID也不會丟失;

如果表的類型是InnoDB，那么是15。因為InnoDB 表只是把自增主鍵的最大ID記錄到內存中，所以重啟數據庫或對表進行OPTION操作，都會導致最大ID丟失。

問題5：哪個存儲引擎執行 select count(*) 更快，為什么?

答：MyISAM更快，因為MyISAM內部維護了一個計數器，可以直接調取。在 MyISAM 存儲引擎中，把表的總行數存儲在磁盤上，當執行 select count(*) from t 時，直接返回總數據。

在 InnoDB 存儲引擎中，跟 MyISAM 不一樣，沒有將總行數存儲在磁盤上，當執行 select count(*) from t 時，會先把數據讀出來，一行一行的累加，最后返回總數量。

InnoDB 中 count(*) 語句是在執行的時候，全表掃描統計總數量，所以當數據越來越大時，語句就越來越耗時了，為什么 InnoDB 引擎不像 MyISAM 引擎一樣，將總行數存儲到磁盤上?這跟 InnoDB 的事務特性有關，由于多版本并發控制(MVCC)的原因，InnoDB 表“應該返回多少行”也是不確定的。

三、數據類型相關

問題6：CHAT和VARCHAR的區別？

答：char是固定長度，varchar長度可變：

char(n) 和 varchar(n) 中括號中 n 代表字符的個數，并不代表字節個數，比如 CHAR(30) 就可以存儲 30 個字符。存儲時，前者不管實際存儲數據的長度，直接按 char 規定的長度分配存儲空間;而后者會根據實際存儲的數據分配最終的存儲空間

相同點：

1、char(n)，varchar(n)中的n都代表字符的個數

2、超過char，varchar最大長度n的限制后，字符串會被截斷。

不同點：

1、char不論實際存儲的字符數都會占用n個字符的空間，而varchar只會占用實際字符應該占用的字節空間加1(實際長度length，0<=length<255)或加2(length>255)。因為varchar保存數據時除了要保存字符串之外還會加一個字節來記錄長度(如果列聲明長度大于255則使用兩個字節來保存長度)。

2、能存儲的最大空間限制不一樣：char的存儲上限為255字節。char在存儲時會截斷尾部的空格，而varchar不會。char是適合存儲很短的、一般固定長度的字符串。例如，char非常適合存儲密碼的MD5值，因為這是一個定長的值。對于非常短的列，char比varchar在存儲空間上也更有效率。

問題7：列的字符串類型可以是什么？

答：字符串類型是：SET、BLOB、ENUM、CHAR、CHAR、TEXT、VARCHAR

問題8：BLOB和TEXT有什么區別？

答：BLOB是一個二進制對象，可以容納可變數量的數據。有四種類型的BLOB：TINYBLOB、BLOB、MEDIUMBLO和 LONGBLOB;

TEXT是一個不區分大小寫的BLOB。四種TEXT類型：TINYTEXT、TEXT、MEDIUMTEXT 和 LONGTEXT。

BLOB 保存二進制數據，TEXT 保存字符數據。

問題9：說說你對MYSQL索引的理解？

答：MYSQL官方對索引的定義為：索引(Index)是幫助MySQL高效獲取數據的數據結構，所以說索引的本質是：數據結構索引的目的在于提高查詢效率，可以類比字典、 火車站的車次表、圖書的目錄等。

可以簡單的理解為“排好序的快速查找數據結構”，數據本身之外，數據庫還維護者一個滿足特定查找算法的數據結構，這些數據結構以某種方式引用(指向)數據，這樣就可以在這些數據結構上實現高級查找算法。這種數據結構，就是索引。下圖是一種可能的索引方式示例。左邊的數據表，一共有兩列七條記錄，最左邊的是數據記錄的物理地址。為了加快Col2的查找，可以維護一個右邊所示的二叉查找樹，每個節點分別包含索引鍵值，和一個指向對應數據記錄物理地址的指針，這樣就可以運用二叉查找在一定的復雜度內獲取到對應的數據，從而快速檢索出符合條件的記錄。

索引本身也很大，不可能全部存儲在內存中，一般以索引文件的形式存儲在磁盤上，平常說的索引，沒有特別指明的話，就是B+樹(多路搜索樹，不一定是二叉樹)結構組織的索引。其中聚集索引，次要索引，覆蓋索引，符合索引，前綴索引，唯一索引默認都是使用B+樹索引，統稱索引。此外還有哈希索引等。

問題10：說說使用索引的優劣是什么？

答：優勢

提高數據檢索效率，降低數據庫IO成本

降低數據排列的成本，降低CPU的消耗

劣勢

索引也是一張表，保存了主鍵和索引字段，并指向實體表的記錄，所以也需要占用內存

雖然索引大大提高了查詢速度，同時卻會降低更新表的速度，如對表進行INSERT、UPDATE和DELETE。因為更新表時，MySQL不僅要保存數據，還要保存一下索引文件每次更新添加了索引列的字段， 都會調整因為更新所帶來的鍵值變化后的索引信息

問題11：為什么MySQL索引中用B+tree，不用二叉樹和B-tree

答：數據庫使用B+樹肯定是為了提升查找效率。

但是具體如何提升查找效率呢?查找數據，最簡單的方式是順序查找。但是對于幾十萬上百萬，甚至上億的數據庫查詢就很慢了。所以要對查找的方式進行優化，熟悉的二分查找，二叉樹可以把速度提升到O(log(n,2))，查詢的瓶頸在于樹的深度，最壞的情況要查找到二叉樹的最深層，由于，每查找深一層，就要訪問更深一層的索引文件。在多達數G的索引文件中，這將是很大的開銷。所以，盡量把數據結構設計的更為‘扁平’一點就可以減少訪問的層數，從根節點到葉子節點只要34次IO即可(一般B+樹索引深度也就是34層)，如果用二叉樹則這顆樹會非常深。在眾多的解決方案中，B-/B+樹很好的適合。B-樹定義具體可以查閱，簡而言之就是中間節點可以多余兩個子節點，而且中間的元素可以是一個域。相比B-樹，B+樹的父節點也必須存在于子節點中，是其中最大或者最小元素，B+樹的節點只存儲索引key值，具體信息的地址存在于葉子節點的地址中。這就使以頁為單位的索引中可以存放更多的節點。減少更多的I/O支出。因此，B+樹成為了數據庫比較優秀的數據結構，MySQL中MyIsAM和InnoDB都是采用的B+樹結構。不同的是前者是非聚集索引，后者主鍵是聚集索引，所謂聚集索引是物理地址連續存放的索引，在取區間的時候，查找速度非常快，但同樣的，插入的速度也會受到影響而降低。聚集索引的物理位置使用鏈表來進行存儲。用B+樹不用B樹考慮的是IO對性能的影響，B樹的每個節點都存儲數據，而B+樹只有葉子節點才存儲數據，所以查找相同數據量的情況下，B樹的高度更高，IO更頻繁。數據庫索引是存儲在磁盤上的，當數據量大時，就不能把整個索引全部加載到內存了，只能逐一加載每一個磁盤頁(對應索引樹的節點)。其中在MySQL底層對B+樹進行進一步優化：在葉子節點中是雙向鏈表，且在鏈表的頭結點和尾節點也是循環指向的。

問題12：那為什么推薦使用整型自增主鍵而不是選擇UUID?

答：UUID是字符串，比整型消耗更多的存儲空間;在B+樹中進行查找時需要跟經過的節點值比較大小，整型數據的比較運算比字符串更快速;

自增的整型索引在磁盤中會連續存儲，在讀取一頁數據時也是連續;UUID是隨機產生的，讀取的上下兩行數據存儲是分散的，不適合執行where id > 5 && id < 20的條件查詢語句。在插入或刪除數據時，整型自增主鍵會在葉子結點的末尾建立新的葉子節點，不會破壞左側子樹的結構;UUID主鍵很容易出現這樣的情況，B+樹為了維持自身的特性，有可能會進行結構的重構，消耗更多的時間。

問題13：為什么非主鍵索引結構葉子節點存儲的是主鍵值?

答：保證數據一致性和節省存儲空間，可以這么理解：商城系統訂單表會存儲一個用戶ID作為關聯外鍵，而不推薦存儲完整的用戶信息，因為當我們用戶表中的信息(真實名稱、手機號、收貨地址···)修改后，不需要再次維護訂單表的用戶數據，同時也節省了存儲空間。

問題14：為什么MySQL索引為何不采用Hash方式?

答：因為Hash索引底層是哈希表，哈希表是一種以key-value存儲數據的結構，所以多個數據在存儲關系上是完全沒有任何順序關系的，所以，對于區間查詢是無法直接通過索引查詢的，就需要全表掃描。所以，哈希索引只適用于等值查詢的場景。而B+ Tree是一種多路平衡查詢樹，所以他的節點是天然有序的(左子節點小于父節點、父節點小于右子節點)，所以對于范圍查詢的時候不需要做全表掃描。哈希索引不支持多列聯合索引的最左匹配規則，如果有大量重復鍵值得情況下，哈希索引的效率會很低，因為存在哈希碰撞問題。

問題15：Mysql哪些情況下需要創建索引，哪些情況下可以不用創建索引

答：

哪些情況需要創建索引：

1、主鍵自動建立唯一索引

2、頻繁作為查詢條件的字段

3、查詢中與其他表關聯的字段，外鍵關系建立索引

4、單鍵/組合索引的選擇問題，高并發下傾向創建組合索引

5、查詢中排序的字段，排序字段通過索引訪問大幅提高排序速度

6、查詢中統計或分組字段

哪些情況不需要創建索引：

1、表記錄太少

2、經常增刪改的表

3、數據重復且分布均勻的表字段，只應該為最經常查詢和最經常排序的數據列建立索引(如果某個數據類包含太多的重復數據，建立索引沒有太大意義)

4、頻繁更新的字段不適合創建索引(會加重IO負擔)

5、where條件里用不到的字段不創建索引

由于篇幅原因，本文不做全部展示，有需要MySql面試資料的同學添加管理員微信獲取，也可以讓管理員邀請你進入測開交流群!

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的mysql测试工作中的应用_Mysql精华总结，解决测试人员面试中的碰到的一切Mysql问题（一）...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。