MySQL奪命15問，你能堅持到第幾問？

前言

MySQL在面試中經(jīng)常被問到，本文總結了面試中的經(jīng)典問題。

1. 數(shù)據(jù)庫三大范式是什么？

第一范式：每個列都不可以再拆分。

第二范式：在第一范式的基礎上，非主鍵列完全依賴于主鍵，而不能是依賴于主鍵的一部分。

第三范式：在第二范式的基礎上，非主鍵列只依賴于主鍵，不依賴于其他非主鍵。

在設計數(shù)據(jù)庫結構的時候，要盡量遵守三范式，如果不遵守，必須有足夠的理由。

比如性能。事實上我們經(jīng)常會為了性能而妥協(xié)數(shù)據(jù)庫的設計。

2. mysql有關權限的表都有哪幾個?

MySQL服務器通過權限表來控制用戶對數(shù)據(jù)庫的訪問，權限表存放在mysql數(shù)據(jù)庫里，由mysql_install_db腳本初始化。

這些權限表分別user，db，table_priv，columns_priv和host。

user權限表：記錄允許連接到服務器的用戶帳號信息，里面的權限是全局級的。

db權限表：記錄各個帳號在各個數(shù)據(jù)庫上的操作權限。

table_priv權限表：記錄數(shù)據(jù)表級的操作權限。

columns_priv權限表：記錄數(shù)據(jù)列級的操作權限。

host權限表：配合db權限表對給定主機上數(shù)據(jù)庫級操作權限作更細致的控制。這個權限表不受GRANT和REVOKE語句的影響。

3. 事務的四大特性(ACID)介紹一下?

原子性：事務是最小的執(zhí)行單位，不允許分割。

事務的原子性確保動作要么全部完成，要么完全不起作用；

一致性：執(zhí)行事務前后，數(shù)據(jù)保持一致，多個事務對同一個數(shù)據(jù)讀取的結果是相同的；

隔離性：并發(fā)訪問數(shù)據(jù)庫時，一個用戶的事務不被其他事務所干擾，

各并發(fā)事務之間數(shù)據(jù)庫是獨立的；

持久性：一個事務被提交之后。它對數(shù)據(jù)庫中數(shù)據(jù)的改變是持久的， 即使數(shù)據(jù)庫發(fā)生故障也不應該對其有任何影響。

4. ?SQL語句主要分為哪幾類?

數(shù)據(jù)定義語言DDL（Data Ddefinition Language）CREATE，DROP，ALTER

主要為以上操作 即對邏輯結構等有操作的，其中包括表結構，視圖和索引。

數(shù)據(jù)查詢語言DQL（Data Query Language）SELECT

這個較為好理解 即查詢操作，以select關鍵字。

各種簡單查詢，連接查詢等 都屬于DQL。

數(shù)據(jù)操縱語言DML（Data Manipulation Language）INSERT，UPDATE，DELETE

主要為以上操作 即對數(shù)據(jù)進行操作的，

對應上面所說的查詢操作 DQL與DML共同構建了多數(shù)初級程序員常用的增刪改查操作。

而查詢是較為特殊的一種 被劃分到DQL中。

數(shù)據(jù)控制功能DCL（Data Control Language）GRANT，REVOKE，COMMIT，ROLLBACK

主要為以上操作 即對數(shù)據(jù)庫安全性完整性等有操作的，可以簡單的理解為權限控制等。

5. MySQL分庫分表的目的是？

分庫分表就是為了 解決由于數(shù)據(jù)量過大而導致數(shù)據(jù)庫性能降低的問題， 將原來獨立的數(shù)據(jù)庫拆分成若干數(shù)據(jù)庫組成，將數(shù)據(jù)大表拆分成若干數(shù)據(jù)表組成， 使得單一數(shù)據(jù)庫、單一數(shù)據(jù)表的數(shù)據(jù)量變小，從而達到提升數(shù)據(jù)庫性能的目的。

分庫分表常用的中間件如下：

6. 什么是死鎖？怎么解決？

死鎖是指兩個或多個事務在同一資源上相互占用，并請求鎖定對方的資源，從而導致惡性循環(huán)的現(xiàn)象。

常見的解決死鎖的方法

1. 如果不同程序會并發(fā)存取多個表， 盡量約定以相同的順序訪問表，可以大大降低死鎖機會。
2. 在同一個事務中，盡可能做到一次鎖定所需要的所有資源，減少死鎖產(chǎn)生概率；
3. 對于非常容易產(chǎn)生死鎖的業(yè)務部分，可以嘗試使用升級鎖定顆粒度，通過表級鎖定來減少死鎖產(chǎn)生的概率；

如果業(yè)務處理不好可以用分布式事務鎖或者使用樂觀鎖

7. ?什么是臟讀？幻讀？不可重復讀？

臟讀(Drity Read)：某個事務已更新一份數(shù)據(jù)，另一個事務在此時讀取了同一份數(shù)據(jù)， 由于某些原因，前一個RollBack了操作，則后一個事務所讀取的數(shù)據(jù)就會是不正確的。

不可重復讀(Non-repeatable read):在一個事務的兩次查詢之中數(shù)據(jù)不一致， 這可能是兩次查詢過程中間插入了一個事務更新的原有的數(shù)據(jù)。

幻讀(Phantom Read):在一個事務的兩次查詢中數(shù)據(jù)筆數(shù)不一致， 例如有一個事務查詢了幾列(Row)數(shù)據(jù)， 而另一個事務卻在此時插入了新的幾列數(shù)據(jù)，先前的事務在接下來的查詢中， 就會發(fā)現(xiàn)有幾列數(shù)據(jù)是它先前所沒有的。

8. ?視圖有哪些特點？

視圖的特點如下: 視圖的列可以來自不同的表，是表的抽象和在邏輯意義上建立的新關系。

視圖是由基本表(實表)產(chǎn)生的表(虛表)。視圖的建立和刪除不影響基本表。

對視圖內(nèi)容的更新(添加，刪除和修改)直接影響基本表。

當視圖來自多個基本表時，不允許添加和刪除數(shù)據(jù)。

視圖的操作包括創(chuàng)建視圖，查看視圖，刪除視圖和修改視圖。

9. SQL的生命周期？

1. 應用服務器與數(shù)據(jù)庫服務器建立一個連接
2. 數(shù)據(jù)庫進程拿到請求sql
3. 解析并生成執(zhí)行計劃，執(zhí)行
4. 讀取數(shù)據(jù)到內(nèi)存并進行邏輯處理
5. 通過步驟一的連接，發(fā)送結果到客戶端
6. 關掉連接，釋放資源

10. 主鍵使用自增ID還是UUID？

推薦使用自增ID，不要使用UUID。

因為在InnoDB存儲引擎中，主鍵索引是作為聚簇索引存在的，也就是說， 主鍵索引的B+樹葉子節(jié)點上存儲了主鍵索引以及全部的數(shù)據(jù)(按照順序)， 如果主鍵索引是自增ID，那么只需要不斷向后排列即可，如果是UUID， 由于到來的ID與原來的大小不確定，會造成非常多的數(shù)據(jù)插入，數(shù)據(jù)移動，然后導致產(chǎn)生很多的內(nèi)存碎片，進而造成插入性能的下降。

總之，在數(shù)據(jù)量大一些的情況下，用自增主鍵性能會好一些。

關于主鍵是聚簇索引，如果沒有主鍵，InnoDB會選擇一個唯一鍵來作為聚簇索引，如果沒有唯一鍵，會生成一個隱式的主鍵。

11. MySQL數(shù)據(jù)庫cpu飆升到100%的話怎么處理？

當 cpu 飆升到 100%時，先用操作系統(tǒng)命令 top 命令觀察是不是 mysqld 占用導致的。

如果不是，找出占用高的進程，并進行相關處理。

如果是 mysqld 造成的， show processlist，看看里面跑的 session 情況，是不是有消耗資源的 sql 在運行。找出消耗高的 sql，看看執(zhí)行計劃是否準確，index 是否缺失，或者實在是數(shù)據(jù)量太大造成。

一般來說，肯定要 kill 掉這些線程(同時觀察 cpu 使用率是否下降)， 等進行相應的調(diào)整(比如說加索引、改 sql、改內(nèi)存參數(shù))之后，再重新跑這些 SQL。

也有可能是每個 sql 消耗資源并不多，但是突然之間，有大量的 session 連進來導致 cpu 飆升， 這種情況就需要跟應用一起來分析為何連接數(shù)會激增， 再做出相應的調(diào)整，比如說限制連接數(shù)等。

12. MySQL主從復制解決了哪些問題？

主從復制的作用是：

主數(shù)據(jù)庫出現(xiàn)問題，可以切換到從數(shù)據(jù)庫?？梢赃M行數(shù)據(jù)庫層面的讀寫分離?？梢栽趶臄?shù)據(jù)庫上進行日常備份。

數(shù)據(jù)分布：隨意開始或停止復制，并在不同地理位置分布數(shù)據(jù)備份

負載均衡：降低單個服務器的壓力

高可用和故障切換：幫助應用程序避免單點失敗

升級測試：可以用更高版本的MySQL作為從庫

13. 什么是MySQL的GTID？

TID（Global Transaction ID，全局事務ID）是全局事務標識符， 是一個已提交事務的編號，并且是一個全局唯一的編號。

GTID是從MySQL 5.6版本開始在主從復制方面推出的重量級特性。

GTID實際上是由UUID+TID組成的。其中UUID是一個MySQL實例的唯一標識。

GTID代表了該實例上已經(jīng)提交的事務數(shù)量，并且隨著事務提交單調(diào)遞增。

GTID有如下幾點作用：

1. 根據(jù)GTID可以知道事務最初是在哪個實例上提交的。
2. GTID的存在方便了Replication的Failover。因為不用像傳統(tǒng)模式復制那樣去找master_log_file和master_log_pos。
3. 基于GTID搭建主從復制更加簡單， 確保每個事務只會被執(zhí)行一次。

14. MySQL常用的備份工具有哪些？

常用備份工具mysql復制

邏輯備份(mysqldump，mydumper)

物理備份(copy,xtrabackup)

備份工具差異對比：

1. mysql復制相對于其他的備份來說，得到的備份數(shù)據(jù)比較實時。
2. 邏輯備份：分表比較容易。mysqldump備份數(shù)據(jù)時是將所有sql語句整合在同一個文件中；mydumper備份數(shù)據(jù)時是將SQL語句按照表拆分成單個的sql文件， 每個sql文件對應一個完整的表。
3. 物理備份：拷貝即可用，速度快。

copy:直接拷貝文件到數(shù)據(jù)目錄下，可能引起表損壞或者數(shù)據(jù)不一致。

xtrabackup對于innodb表是不需要鎖表的，對于myisam表仍然需要鎖表。

15. MySQL備份計劃如何制定

視庫的大小來定，一般來說 100G 內(nèi)的庫，可以考慮使用 mysqldump 來做， 因為 mysqldump更加輕巧靈活，備份時間選在業(yè)務低峰期， 可以每天進行都進行全量備份(mysqldump 備份出來的文件比較小，壓縮之后更小)。

100G 以上的庫，可以考慮用 xtranbackup 來做，備份速度明顯要比 mysqldump 要快。

一般是選擇一周一個全備，其余每天進行增量備份，備份時間為業(yè)務低峰期。

文章中出現(xiàn)的關于面試題的錯誤請在評論區(qū)指出，我再進行改正優(yōu)化。如果文章對你有所幫助，請給一個免費的贊吧，感謝大家。