Mysql高頻面試題

時間 2021-08-12

標籤 mysql 面試算法 sql 數據庫安全服務器網絡數據結構併發欄目 MySQL 简体版

原文原文鏈接

一、Mysql中有哪幾種鎖？mysql

MyISAM 支持表鎖，InnoDB 支持表鎖和行鎖，默認爲行鎖。面試

表級鎖:開銷小，加鎖快，不會出現死鎖。鎖定粒度大，發生鎖衝突的機率最高，併發量最低。算法
行級鎖:開銷大，加鎖慢，會出現死鎖。鎖力度小，發生鎖衝突的機率小，併發度最高。sql

二、Mysql支持事務嗎？數據庫

在缺省模式下，MYSQL 是 autocommit 模式的，全部的數據庫更新操做都會即時提交，所以在缺省狀況下，mysql 是不支持事務的。可是若是你的 MYSQL 表類型是使用 InnoDB Tables 或 BDB tables 的話，你的 MYSQL 就能夠使用事務處理,使用 SET AUTOCOMMIT=0 就可使 MYSQL 容許在非 autocommit 模式，在非autocommit 模式下，你必須使用 COMMIT 來提交你的更改，或者用 ROLLBACK 來回滾你的更改。

示例以下：安全

START TRANSACTION;SELECT @A:=SUM(salary) FROM table1 WHERE type=1;UPDATE table2 SET summmary=@A WHERE type=1;COMMIT;

三、Mysql查詢是否區分大小寫？服務器

不區分。網絡

SELECT VERSION(), CURRENT_DATE;SeLect version(), current_date;seleCt vErSiOn(), current_DATE;

這幾個例子都是同樣的，Mysql 不區分大小寫。數據結構

四、列設置爲 AUTO INCREMENT 時，若是在表中達到最大值，會發生什麼狀況?併發

答：它會中止遞增，任何進一步的插入都將產生錯誤，由於密鑰已被使用。

五、一張表，裏面有 ID 自增主鍵，當 insert 了 17 條記錄以後，刪除了第 15,16,17 條記錄，再把 Mysql 重啓，再 insert 一條記錄，這條記錄的 ID 是 18 仍是 15 ?

若是表的類型是 MyISAM，那麼是 18。由於 MyISAM 表會把自增主鍵的最大 ID 記錄到數據文件裏，重啓 MySQL 自增主鍵的最大ID 也不會丟失。
若是表的類型是 InnoDB，那麼是 15。InnoDB 表只是把自增主鍵的最大 ID 記錄到內存中，因此重啓數據庫或者是對錶進行OPTIMIZE 操做，都會致使最大 ID 丟失。

六、數據庫三範式是什麼?

第一範式(1NF):字段具備原子性,不可再分。(全部關係型數據庫系統都知足第一範式數據庫表中的字段都是單一屬性的，不可再分)
第二範式(2NF)是在第一範式(1NF)的基礎上創建起來的，即知足第二範式(2NF)必須先知足第一範式(1NF)。要求數據庫表中的每個實例或行必須能夠被唯一地區分。一般須要爲表加上一個列，以存儲各個實例的唯一標識。這個唯一屬性列被稱爲主關鍵字或主鍵。
知足第三範式(3NF)必須先知足第二範式(2NF)。簡而言之，第三範式(3NF)要求一個數據庫表中不包含已在其它表中已包含的非主關鍵字信息。>因此第三範式具備以下特徵: >>1. 每一列只有一個值 >>2. 每一行都能區分。>>3. 每個表都不包含其餘表已經包含的非主關鍵字信息。

七、mysql 的複製原理以及流程？

答： Mysql 內建的複製功能是構建大型，高性能應用程序的基礎。將 Mysql 的數據分佈到多個系統上去，這種分佈的機制，是經過將 Mysql 的某一臺主機的數據複製到其它主機(slaves)上，並從新執行一遍來實現的。* 複製過程當中一個服務器充當主服務器，而一個或多個其它服務器充當從服務器。主服務器將更新寫入二進制日誌文件，並維護文件的一個索引以跟蹤日誌循環。這些日誌能夠記錄發送到從服務器的更新。當一個從服務器鏈接主服務器時，它通知主服務器在日誌中讀取的最後一次成功更新的位置。從服務器接收從那時起發生的任何更新，而後封鎖並等待主服務器通知新的更新。過程以下： 1. 主服務器把更新記錄到二進制日誌文件中。 2. 從服務器把主服務器的二進制日誌拷貝到本身的中繼日誌(replay log)中。 3. 從服務器重作中繼日誌中的時間，把更新應用到本身的數據庫上。

八、mysql 中 myISAM與 innodb 的區別?

1. 事務支持 > MyISAM:強調的是性能，每次查詢具備原子性,其執行數度比 InnoDB 類型更快，可是不提供事務支持。> InnoDB:提供事務支持事務，外部鍵等高級數據庫功能。具備事務(commit)、回滾 (rollback)和崩潰修復能力(crash recovery capabilities)的事務安全 (transaction-safe (ACID compliant))型表。

2. InnoDB 支持行級鎖，而 MyISAM 支持表級鎖. >> 用戶在操做 myisam 表時，select，update，delete，insert 語句都會給表自動加鎖，若是加鎖之後的表知足 insert 併發的狀況下，能夠在表的尾部插入新的數據。

3. InnoDB 支持 MVCC, 而 MyISAM 不支持。

4.InnoDB支持外鍵，而MyISAM不支持。

5.表主鍵 > MyISAM:容許沒有任何索引和主鍵的表存在，索引都是保存行的地址。> InnoDB:若是沒有設定主鍵或者非空惟一索引，就會自動生成一個 6 字節的主鍵(用戶不可見)，數據是主索引的一部分，附加索引保存的是主索引的值。

6.InnoDB不支持全文索引，而MyISAM支持。

7.可移植性、備份及恢復 > MyISAM:數據是以文件的形式存儲，因此在跨平臺的數據轉移中會很方便。在備份和恢復時可單獨針對某個表進行操做。> InnoDB:免費的方案能夠是拷貝數據文件、備份 binlog，或者用 mysqldump，在數據量達到幾十 G 的時候就相對痛苦了。

8.存儲結構 > MyISAM:每一個 MyISAM 在磁盤上存儲成三個文件。第一個文件的名字以表的名字開始，擴展名指出文件類型。.frm 文件存儲表定義。數據文件的擴展名爲.MYD (MYData)。索引文件的擴展名是.MYI (MYIndex)。> InnoDB:全部的表都保存在同一個數據文件中(也多是多個文件，或者是獨立的表空間文件)，InnoDB 表的大小隻受限於操做系統文件的大小，通常爲 2GB。

九、MySQL 中 InnoDB 支持的四種事務隔離級別名稱，以及逐級之間的區別?

1. Read Uncommitted(讀取未提交內容) >> 在該隔離級別，全部事務均可以看到其餘未提交事務的執行結果。本隔離級別不多用於實際應用，由於它的性能也不比其餘級別好多少。讀取未提交的數據，也被稱之爲髒讀(Dirty Read)。

2. Read Committed(讀取提交內容) >> 這是大多數數據庫系統的默認隔離級別(但不是 MySQL 默認的)。它知足了隔離的簡單定義:一個事務只能看見已經提交事務所作的改變。這種隔離級別也支持所謂的不可重複讀(Nonrepeatable Read)，由於同一事務的其餘實例在該實例處理其間可能會有新的 commit，因此同一 select 可能返回不一樣結果。

3. Repeatable Read(可重讀) >> 這是 MySQL 的默認事務隔離級別，它確保同一事務的多個實例在併發讀取數據時，會看到一樣的數據行。不過理論上，這會致使另外一個棘手的問題:幻讀(Phantom Read)。簡單的說，幻讀指當用戶讀取某一範圍的數據行時，另外一個事務又在該範圍內插入了新行，當用戶再讀取該範圍的數據行時，會發現有新的「幻影」行。InnoDB 和 Falcon 存儲引擎經過多版本併發控制(MVCC，Multiversion Concurrency Control 間隙鎖)機制解決了該問題。注:其實多版本只是解決不可重複讀問題，而加上間隙鎖(也就是它這裏所謂的併發控制)才解決了幻讀問題。

4. Serializable(可串行化) >> 這是最高的隔離級別，它經過強制事務排序，使之不可能相互衝突，從而解決幻讀問題。簡言之，它是在每一個讀的數據行上加上共享鎖。在這個級別，可能致使大量的超時現象和鎖競爭。

十、[SELECT *] 和[SELECT 所有字段]的 2 種寫法有何優缺點?

1. 前者要解析數據字典，後者不須要
2. 結果輸出順序，前者與建表列順序相同，後者按指定字段順序。

3. 表字段更名，前者不須要修改，後者須要改
4. 後者能夠創建索引進行優化，前者沒法優化
5. 後者的可讀性比前者要高

十一、簡述 Mybatis 的插件運行原理，以及如何編寫一個插件?

Mybatis 僅能夠編寫針對 ParameterHandler、ResultSetHandler、StatementHandler、 Executor 這 4 種接口的插件，Mybatis 經過動態代理，爲須要攔截的接口生成代理對象以實現接口方法攔截功能，每當執行這 4 種接口對象的方法時，就會進入攔截方法，具體就是 InvocationHandler 的 invoke()方法，固然，只會攔截那些你指定須要攔截的方法。
實現 Mybatis 的 Interceptor 接口並複寫 intercept()方法，而後在給插件編寫註解，指定要攔截哪個接口的哪些方法便可，記住，別忘了在配置文件中配置你編寫的插件。

十二、#{}和${}的區別是什麼?

#{}是預編譯處理，${}是字符串替換。
Mybatis 在處理#{}時，會將 sql 中的#{}替換爲?號，調用 PreparedStatement 的 set 方法來賦值。
Mybatis 在處理${}時，就是把${}替換成變量的值。
使用#{}能夠有效的防止 SQL 注入，提升系統安全性。

1三、什麼是索引？請簡述經常使用的索引有哪些種類?

索引是對數據庫表中一列或多列的值進行排序的一種結構，使用索引可快速訪問數據庫表中的特定信息。若是想按特定職員的姓來查找他或她，則在表中搜索全部的行相比，索引有助於更快地獲取信息
通俗的講，索引就是數據的目錄，就像看書同樣，假如我想看第三章第四節的內容，若是有目錄，我直接翻目錄，找到第三章第四節的頁碼便可。若是沒有目錄，我就須要將從書的開頭開始，一頁一頁翻，直到翻到第三章第四節的內容。

MySQL索引的分類

咱們根據對以列屬性生成的索引大體分爲兩類：

單列索引：以該表的單個列，生成的索引樹，就稱爲該表的單列索引
組合索引：以該表的多個列組合，一塊兒生成的索引樹，就稱爲該表的組合索引。

單列索引又有具體細的劃分：

主鍵索引：以該表主鍵生成的索引樹，就稱爲該表的主鍵索引。
惟一索引：以該表惟一列生成的索引樹，就稱爲該表的惟一索引。
普通索引：以該表的普通列（非主鍵，非惟一列）生成的索引樹，就稱爲該表的普通索引。
全文索引

1四、索引是個什麼樣的數據結構呢?

答：索引的數據結構和具體存儲引擎的實現有關, 在MySQL中使用較多的索引有Hash索引,B+樹索引等。而咱們常用的InnoDB存儲引擎的默認索引實現爲:B+樹索引。

1五、Hash索引和B+樹全部有什麼區別或者說優劣呢?

答：首先要知道Hash索引和B+樹索引的底層實現原理:

hash索引底層就是hash表，進行查找時，調用一次hash函數就能夠獲取到相應的鍵值，以後進行回表查詢得到實際數據。
B+樹底層實現是多路平衡查找樹，對於每一次的查詢都是從根節點出發，查找到葉子節點方能夠得到所查鍵值，而後根據查詢判斷是否須要回表查詢數據。

那麼能夠看出他們有如下的不一樣：

hash索引進行等值查詢更快(通常狀況下)，可是卻沒法進行範圍查詢。由於在hash索引中通過hash函數創建索引以後，索引的順序與原順序沒法保持一致，不能支持範圍查詢。而B+樹的的全部節點皆遵循(左節點小於父節點，右節點大於父節點，多叉樹也相似)，自然支持範圍。
hash索引不支持使用索引進行排序，原理同上。
hash索引不支持模糊查詢以及多列索引的最左前綴匹配.原理也是由於hash函數的不可預測，AAAA和AAAAB的索引沒有相關性。
hash索引任什麼時候候都避免不了回表查詢數據，而B+樹在符合某些條件(聚簇索引，覆蓋索引等)的時候能夠只經過索引完成查詢。
hash索引雖然在等值查詢上較快，可是不穩定，性能不可預測。當某個鍵值存在大量重複的時候，發生hash碰撞，此時效率可能極差。而B+樹的查詢效率比較穩定，對於全部的查詢都是從根節點到葉子節點，且樹的高度較低。

所以，在大多數狀況下，直接選擇B+樹索引能夠得到穩定且較好的查詢速度。而不須要使用hash索引。

1六、上面提到了B+樹在知足聚簇索引和覆蓋索引的時候不須要回表查詢數據,什麼是聚簇索引?

答：在B+樹的索引中，葉子節點可能存儲了當前的key值，也可能存儲了當前的key值以及整行的數據，這就是聚簇索引和非聚簇索引.。在InnoDB中，只有主鍵索引是聚簇索引，若是沒有主鍵，則挑選一個惟一鍵創建聚簇索引，若是沒有惟一鍵，則隱式的生成一個鍵來創建聚簇索引。當查詢使用聚簇索引時，在對應的葉子節點，能夠獲取到整行數據,所以不用再次進行回表查詢。

1七、非聚簇索引必定會回表查詢嗎?

答：不必定。這涉及到查詢語句所要求的字段是否所有命中了索引，若是所有命中了索引，那麼就沒必要再進行回表查詢。舉個簡單的例子，假設咱們在員工表的年齡上創建了索引，那麼當進行select age from employee where age < 20的查詢時，在索引的葉子節點上，已經包含了age信息，不會再次進行回表查詢。

1八、對MySQL的鎖瞭解嗎?

答：當數據庫有併發事務的時候，可能會產生數據的不一致，這時候須要一些機制來保證訪問的次序，鎖機制就是這樣的一個機制。就像酒店的房間，若是你們隨意進出，就會出現多人搶奪同一個房間的狀況，而在房間上裝上鎖，申請到鑰匙的人才能夠入住而且將房間鎖起來，其餘人只有等他使用完畢才能夠再次使用。

1九、MySQL都有哪些鎖呢?像上面的例子進行鎖定豈不是有點阻礙併發效率了?

答：從鎖的類別上來說，有共享鎖和排他鎖。

共享鎖：又叫作讀鎖，當用戶要進行數據的讀取時，對數據加上共享鎖，共享鎖能夠同時加上多個。
排他鎖：又叫作寫鎖，當用戶要進行數據的寫入時，對數據加上排他鎖，排他鎖只能夠加一個，他和其餘的排他鎖，共享鎖都相斥。

用上面的例子來講就是用戶的行爲有兩種，一種是來看房，多個用戶一塊兒看房是能夠接受的。一種是真正的入住一晚，在這期間，不管是想入住的仍是想看房的都不能夠。

鎖的粒度取決於具體的存儲引擎，InnoDB實現了行級鎖，頁級鎖，表級鎖。他們的加鎖開銷從大大小，併發能力也是從大到小。

20、MySQL的binlog有有幾種錄入格式?分別有什麼區別?

答：有三種格式,statement,row和mixed。

statement模式下，記錄單元爲語句。即每個sql形成的影響會記錄，因爲sql的執行是有上下文的，所以在保存的時候須要保存相關的信息，同時還有一些使用了函數之類的語句沒法被記錄複製。
row級別下，記錄單元爲每一行的改動，基本是能夠所有記下來可是因爲不少操做，會致使大量行的改動(好比alter table)，所以這種模式的文件保存的信息太多，日誌量太大。
mixed，一種折中的方案，普通操做使用statement記錄，當沒法使用statement的時候使用row。

此外，新版的MySQL中對row級別也作了一些優化，當表結構發生變化的時候，會記錄語句而不是逐行記錄。

2一、一條sql執行過長的時間，你如何優化，從哪些方面？

一、查看sql是否涉及多表的聯表或者子查詢，若是有，看是否能進行業務拆分，相關字段冗餘或者合併成臨時表（業務和算法的優化）。二、涉及鏈表的查詢，是否能進行分表查詢，單表查詢以後的結果進行字段整合。三、若是以上兩種都不能操做，非要鏈表查詢，那麼考慮對相對應的查詢條件作索引。加快查詢速度。四、針對數量大的表進行歷史表分離（如交易流水錶）。五、數據庫主從分離，讀寫分離，下降讀寫針對同一表同時的壓力，至於主從同步，mysql有自帶的binlog實現主從同步。六、 explain 分析sql語句，查看執行計劃，分析索引是否用上，分析掃描行數等等。七、查看mysql執行日誌，看看是否有其餘方面的問題。

上面我將 explain 關鍵字加粗顯示，就是不少面試官他並不直接問你sql優化，他會問你知道什麼是mysql的執行計劃嗎？其實就是想考你知不知道explain關鍵字，因此鄉親們對explain這個不瞭解的，還須要本身線下去網上查看學習一下哦。

公衆號近期薦讀：