快問快答，MySQL面試奪命20問
數(shù)據(jù)庫架構
說說MySQL 的基礎架構圖
給面試官講一下 MySQL 的邏輯架構，有白板可以把下面的圖畫一下，圖片來源于網(wǎng)絡。
Mysql邏輯架構圖主要分三層：
（1）第一層負責連接處理，授權認證，安全等等
（2）第二層負責編譯并優(yōu)化SQL
（3）第三層是存儲引擎。
一條SQL查詢語句在MySQL中如何執(zhí)行的？
先檢查該語句 是否有權限，如果沒有權限，直接返回錯誤信息，如果有權限會先查詢緩存(MySQL8.0 版本以前)。如果沒有緩存，分析器進行 詞法分析，提取 sql 語句中 select 等關鍵元素，然后判斷 sql 語句是否有語法錯誤，比如關鍵詞是否正確等等。最后優(yōu)化器確定執(zhí)行方案進行權限校驗，如果沒有權限就直接返回錯誤信息，如果有權限就會 調(diào)用數(shù)據(jù)庫引擎接口，返回執(zhí)行結果。
SQL 優(yōu)化
日常工作中你是怎么優(yōu)化SQL的？
可以從這幾個維度回答這個問題：
1，優(yōu)化表結構
（1）盡量使用數(shù)字型字段
若只含數(shù)值信息的字段盡量不要設計為字符型，這會降低查詢和連接的性能，并會增加存儲開銷。這是因為引擎在處理查詢和連接時會逐個比較字符串中每一個字符，而對于數(shù)字型而言只需要比較一次就夠了。
（2）盡可能的使用 varchar 代替 char
變長字段存儲空間小，可以節(jié)省存儲空間。
（3）當索引列大量重復數(shù)據(jù)時，可以把索引刪除掉
比如有一列是性別，幾乎只有男、女、未知，這樣的索引是無效的。
2，優(yōu)化查詢
應盡量避免在 where 子句中使用!=或<>操作符 應盡量避免在 where 子句中使用 or 來連接條件 任何查詢也不要出現(xiàn)select * 避免在 where 子句中對字段進行 null 值判斷
3，索引優(yōu)化
對作為查詢條件和 order by的字段建立索引 避免建立過多的索引，多使用組合索引
怎么看執(zhí)行計劃（explain），如何理解其中各個字段的含義？
在 select 語句之前增加 explain 關鍵字，會返回執(zhí)行計劃的信息。
（1）id 列：是 select 語句的序號，MySQL將 select 查詢分為簡單查詢和復雜查詢。
（2）select_type列：表示對應行是是簡單還是復雜的查詢。
（3）table 列：表示 explain 的一行正在訪問哪個表。
（4）type 列：最重要的列之一。表示關聯(lián)類型或訪問類型，即 MySQL 決定如何查找表中的行。從最優(yōu)到最差分別為：system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL
（5）possible_keys 列：顯示查詢可能使用哪些索引來查找。
（6）key 列：這一列顯示 mysql 實際采用哪個索引來優(yōu)化對該表的訪問。
（7）key_len 列：顯示了mysql在索引里使用的字節(jié)數(shù)，通過這個值可以算出具體使用了索引中的哪些列。
（8）ref 列：這一列顯示了在key列記錄的索引中，表查找值所用到的列或常量，常見的有：const（常量），func，NULL，字段名。
（9）rows 列：這一列是 mysql 估計要讀取并檢測的行數(shù)，注意這個不是結果集里的行數(shù)。
（10）Extra 列：顯示額外信息。比如有 Using index、Using where、Using temporary等。
關心過業(yè)務系統(tǒng)里面的sql耗時嗎？統(tǒng)計過慢查詢嗎？對慢查詢都怎么優(yōu)化過？
我們平時寫Sql時，都要養(yǎng)成用explain分析的習慣。慢查詢的統(tǒng)計，運維會定期統(tǒng)計給我們
優(yōu)化慢查詢思路：
分析語句，是否加載了不必要的字段/數(shù)據(jù) 分析 SQL 執(zhí)行句話，是否命中索引等 如果 SQL 很復雜，優(yōu)化 SQL 結構 如果表數(shù)據(jù)量太大，考慮分表
索引
聚集索引與非聚集索引的區(qū)別
可以按以下四個維度回答：
（1）一個表中只能擁有一個聚集索引，而非聚集索引一個表可以存在多個。
（2）聚集索引，索引中鍵值的邏輯順序決定了表中相應行的物理順序；非聚集索引，索引中索引的邏輯順序與磁盤上行的物理存儲順序不同。
（3）索引是通過二叉樹的數(shù)據(jù)結構來描述的，我們可以這么理解聚簇索引：索引的葉節(jié)點就是數(shù)據(jù)節(jié)點。而非聚簇索引的葉節(jié)點仍然是索引節(jié)點，只不過有一個指針指向?qū)臄?shù)據(jù)塊。
（4）聚集索引：物理存儲按照索引排序；非聚集索引：物理存儲不按照索引排序；
為什么要用 B+ 樹，為什么不用普通二叉樹？
可以從幾個維度去看這個問題，查詢是否夠快，效率是否穩(wěn)定，存儲數(shù)據(jù)多少，以及查找磁盤次數(shù)，為什么不是普通二叉樹，為什么不是平衡二叉樹，為什么不是B樹，而偏偏是 B+ 樹呢？
（1）為什么不是普通二叉樹？
如果二叉樹特殊化為一個鏈表，相當于全表掃描。平衡二叉樹相比于二叉查找樹來說，查找效率更穩(wěn)定，總體的查找速度也更快。
（2）為什么不是平衡二叉樹呢？
我們知道，在內(nèi)存比在磁盤的數(shù)據(jù)，查詢效率快得多。如果樹這種數(shù)據(jù)結構作為索引，那我們每查找一次數(shù)據(jù)就需要從磁盤中讀取一個節(jié)點，也就是我們說的一個磁盤塊，但是平衡二叉樹可是每個節(jié)點只存儲一個鍵值和數(shù)據(jù)的，如果是B樹，可以存儲更多的節(jié)點數(shù)據(jù)，樹的高度也會降低，因此讀取磁盤的次數(shù)就降下來啦，查詢效率就快啦。
（3）為什么不是 B 樹而是 B+ 樹呢？
B+ 樹非葉子節(jié)點上是不存儲數(shù)據(jù)的，僅存儲鍵值，而B樹節(jié)點中不僅存儲鍵值，也會存儲數(shù)據(jù)。innodb中頁的默認大小是16KB，如果不存儲數(shù)據(jù)，那么就會存儲更多的鍵值，相應的樹的階數(shù)（節(jié)點的子節(jié)點樹）就會更大，樹就會更矮更胖，如此一來我們查找數(shù)據(jù)進行磁盤的IO次數(shù)有會再次減少，數(shù)據(jù)查詢的效率也會更快。
B+ 樹索引的所有數(shù)據(jù)均存儲在葉子節(jié)點，而且數(shù)據(jù)是按照順序排列的，鏈表連著的。那么 B+ 樹使得范圍查找，排序查找，分組查找以及去重查找變得異常簡單。
Hash 索引和 B+ 樹索引區(qū)別是什么？你在設計索引是怎么抉擇的？
B+ 樹可以進行范圍查詢，Hash 索引不能。 B+ 樹支持聯(lián)合索引的最左側(cè)原則，Hash 索引不支持。 B+ 樹支持 order by 排序，Hash 索引不支持。 Hash 索引在等值查詢上比 B+ 樹效率更高。 B+ 樹使用 like 進行模糊查詢的時候，like 后面（比如%開頭）的話可以起到優(yōu)化的作用，Hash 索引根本無法進行模糊查詢。
什么是最左前綴原則？什么是最左匹配原則？
最左前綴原則，就是最左優(yōu)先，在創(chuàng)建多列索引時，要根據(jù)業(yè)務需求，where 子句中使用最頻繁的一列放在最左邊。
當我們創(chuàng)建一個組合索引的時候，如 (a1,a2,a3)，相當于創(chuàng)建了（a1）、(a1,a2)和(a1,a2,a3)三個索引，這就是最左匹配原則。
索引不適合哪些場景?
數(shù)據(jù)量少的不適合加索引 更新比較頻繁的也不適合加索引 = 區(qū)分度低的字段不適合加索引（如性別）
索引有哪些優(yōu)缺點？
(1) 優(yōu)點：
唯一索引可以保證數(shù)據(jù)庫表中每一行的數(shù)據(jù)的唯一性 索引可以加快數(shù)據(jù)查詢速度，減少查詢時間
(2)缺點：
創(chuàng)建索引和維護索引要耗費時間 索引需要占物理空間，除了數(shù)據(jù)表占用數(shù)據(jù)空間之外，每一個索引還要占用一定的物理空間 以表中的數(shù)據(jù)進行增、刪、改的時候，索引也要動態(tài)的維護。
鎖
MySQL 遇到過死鎖問題嗎，你是如何解決的？
遇到過。我排查死鎖的一般步驟是醬紫的：
（1）查看死鎖日志 show engine innodb status; （2）找出死鎖Sql （3）分析sql加鎖情況 （4）模擬死鎖案發(fā) （5）分析死鎖日志 （6）分析死鎖結果
說說數(shù)據(jù)庫的樂觀鎖和悲觀鎖是什么以及它們的區(qū)別？
（1）悲觀鎖：
悲觀鎖她專一且缺乏安全感了，她的心只屬于當前事務，每時每刻都擔心著它心愛的數(shù)據(jù)可能被別的事務修改，所以一個事務擁有（獲得）悲觀鎖后，其他任何事務都不能對數(shù)據(jù)進行修改啦，只能等待鎖被釋放才可以執(zhí)行。
（2）樂觀鎖：
樂觀鎖的“樂觀情緒”體現(xiàn)在，它認為數(shù)據(jù)的變動不會太頻繁。因此，它允許多個事務同時對數(shù)據(jù)進行變動。
實現(xiàn)方式：樂觀鎖一般會使用版本號機制或CAS算法實現(xiàn)。
MVCC 熟悉嗎，知道它的底層原理？
MVCC (Multiversion Concurrency Control)，即多版本并發(fā)控制技術。
MVCC在MySQL InnoDB中的實現(xiàn)主要是為了提高數(shù)據(jù)庫并發(fā)性能，用更好的方式去處理讀-寫沖突，做到即使有讀寫沖突時，也能做到不加鎖，非阻塞并發(fā)讀。
事務
MySQL事務得四大特性以及實現(xiàn)原理
原子性：事務作為一個整體被執(zhí)行，包含在其中的對數(shù)據(jù)庫的操作要么全部被執(zhí)行，要么都不執(zhí)行。 一致性：指在事務開始之前和事務結束以后，數(shù)據(jù)不會被破壞，假如A賬戶給B賬戶轉(zhuǎn)10塊錢，不管成功與否，A和B的總金額是不變的。 隔離性：多個事務并發(fā)訪問時，事務之間是相互隔離的，即一個事務不影響其它事務運行效果。簡言之，就是事務之間是進水不犯河水的。 持久性：表示事務完成以后，該事務對數(shù)據(jù)庫所作的操作更改，將持久地保存在數(shù)據(jù)庫之中。
事務的隔離級別有哪些？MySQL的默認隔離級別是什么？
讀未提交（Read Uncommitted） 讀已提交（Read Committed） 可重復讀（Repeatable Read） 串行化（Serializable）
Mysql默認的事務隔離級別是可重復讀(Repeatable Read)
什么是幻讀，臟讀，不可重復讀呢？
事務A、B交替執(zhí)行，事務A被事務B干擾到了，因為事務A讀取到事務B未提交的數(shù)據(jù)，這就是臟讀。
在一個事務范圍內(nèi)，兩個相同的查詢，讀取同一條記錄，卻返回了不同的數(shù)據(jù)，這就是不可重復讀。
事務A查詢一個范圍的結果集，另一個并發(fā)事務B往這個范圍中插入/刪除了數(shù)據(jù)，并靜悄悄地提交，然后事務A再次查詢相同的范圍，兩次讀取得到的結果集不一樣了，這就是幻讀。
實戰(zhàn)
MySQL數(shù)據(jù)庫cpu飆升的話，要怎么處理呢？
排查過程：
（1）使用top 命令觀察，確定是mysqld導致還是其他原因。（2）如果是mysqld導致的，show processlist，查看session情況，確定是不是有消耗資源的sql在運行。（3）找出消耗高的 sql，看看執(zhí)行計劃是否準確， 索引是否缺失，數(shù)據(jù)量是否太大。
處理：
（1）kill 掉這些線程(同時觀察 cpu 使用率是否下降)， （2）進行相應的調(diào)整(比如說加索引、改 sql、改內(nèi)存參數(shù)) （3）重新跑這些 SQL。
其他情況：
也有可能是每個 sql 消耗資源并不多，但是突然之間，有大量的 session 連進來導致 cpu 飆升，這種情況就需要跟應用一起來分析為何連接數(shù)會激增，再做出相應的調(diào)整，比如說限制連接數(shù)等
MYSQL的主從延遲，你怎么解決？
主從復制分了五個步驟進行：（圖片來源于網(wǎng)絡）
步驟一：主庫的更新事件(update、insert、delete)被寫到binlog 步驟二：從庫發(fā)起連接，連接到主庫。 步驟三：此時主庫創(chuàng)建一個binlog dump thread，把binlog的內(nèi)容發(fā)送到從庫。 步驟四：從庫啟動之后，創(chuàng)建一個I/O線程，讀取主庫傳過來的binlog內(nèi)容并寫入到relay log 步驟五：還會創(chuàng)建一個SQL線程，從relay log里面讀取內(nèi)容，從Exec_Master_Log_Pos位置開始執(zhí)行讀取到的更新事件，將更新內(nèi)容寫入到slave的db
主從同步延遲的原因
一個服務器開放Ｎ個鏈接給客戶端來連接的，這樣有會有大并發(fā)的更新操作, 但是從服務器的里面讀取binlog的線程僅有一個，當某個SQL在從服務器上執(zhí)行的時間稍長 或者由于某個SQL要進行鎖表就會導致，主服務器的SQL大量積壓，未被同步到從服務器里。這就導致了主從不一致， 也就是主從延遲。
主從同步延遲的解決辦法
主服務器要負責更新操作，對安全性的要求比從服務器要高，所以有些設置參數(shù)可以修改，比如sync_binlog=1，innodb_flush_log_at_trx_commit = 1 之類的設置等。 選擇更好的硬件設備作為slave。 把一臺從服務器當度作為備份使用， 而不提供查詢， 那邊他的負載下來了， 執(zhí)行relay log 里面的SQL效率自然就高了。 增加從服務器嘍，這個目的還是分散讀的壓力，從而降低服務器負載。
如果讓你做分庫與分表的設計，簡單說說你會怎么做？
分庫分表方案:
水平分庫：以字段為依據(jù)，按照一定策略（hash、range等），將一個庫中的數(shù)據(jù)拆分到多個庫中。 水平分表：以字段為依據(jù)，按照一定策略（hash、range等），將一個表中的數(shù)據(jù)拆分到多個表中。 垂直分庫：以表為依據(jù)，按照業(yè)務歸屬不同，將不同的表拆分到不同的庫中。 垂直分表：以字段為依據(jù)，按照字段的活躍性，將表中字段拆到不同的表（主表和擴展表）中。
常用的分庫分表中間件：
sharding-jdbc Mycat
分庫分表可能遇到的問題
事務問題：需要用分布式事務啦 跨節(jié)點Join的問題：解決這一問題可以分兩次查詢實現(xiàn) 跨節(jié)點的count,order by,group by以及聚合函數(shù)問題：分別在各個節(jié)點上得到結果后在應用程序端進行合并。 數(shù)據(jù)遷移，容量規(guī)劃，擴容等問題 ID問題：數(shù)據(jù)庫被切分后，不能再依賴數(shù)據(jù)庫自身的主鍵生成機制啦，最簡單可以考慮UUID 跨分片的排序分頁問題
程序汪資料鏈接
堪稱神級的Spring Boot手冊，從基礎入門到實戰(zhàn)進階
臥槽！字節(jié)跳動《算法中文手冊》火了，完整版 PDF 開放下載！
臥槽！阿里大佬總結的《圖解Java》火了，完整版PDF開放下載！
字節(jié)跳動總結的設計模式 PDF 火了，完整版開放下載！
歡迎添加程序汪個人微信 itwang007 進粉絲群或圍觀朋友圈