MySQL有關(guān)知識(shí)點(diǎn)有哪些

2024-07-24 12:33:15

字體：大中小

供稿：網(wǎng)友

　　這篇文章主要介紹了MySQL相關(guān)知識(shí)點(diǎn)有哪些，具有一定借鑒價(jià)值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。

　　1、數(shù)據(jù)庫(kù)架構(gòu)

　　1.1、說(shuō)說(shuō)MySQL 的基礎(chǔ)架構(gòu)圖

　　給面試官講一下 MySQL 的邏輯架構(gòu)，有白板可以把下面的圖畫一下，圖片來(lái)源于網(wǎng)絡(luò)。

　　MySQL相關(guān)知識(shí)點(diǎn)有哪些

　　Mysql邏輯架構(gòu)圖主要分三層：

　　（1）第一層負(fù)責(zé)連接處理，授權(quán)認(rèn)證，安全等等

　　（2）第二層負(fù)責(zé)編譯并優(yōu)化SQL

　　（3）第三層是存儲(chǔ)引擎。

　　1.2、一條SQL查詢語(yǔ)句在MySQL中如何執(zhí)行的？

　　先檢查該語(yǔ)句是否有權(quán)限，如果沒(méi)有權(quán)限，直接返回錯(cuò)誤信息，如果有權(quán)限會(huì)先查詢緩存(MySQL8.0 版本以前)。

　　如果沒(méi)有緩存，分析器進(jìn)行詞法分析，提取 sql 語(yǔ)句中 select 等關(guān)鍵元素，然后判斷 sql 語(yǔ)句是否有語(yǔ)法錯(cuò)誤，比如關(guān)鍵詞是否正確等等。

　　最后優(yōu)化器確定執(zhí)行方案進(jìn)行權(quán)限校驗(yàn)，如果沒(méi)有權(quán)限就直接返回錯(cuò)誤信息，如果有權(quán)限就會(huì)調(diào)用數(shù)據(jù)庫(kù)引擎接口，返回執(zhí)行結(jié)果。

　　2、SQL 優(yōu)化

　　2.1、日常工作中你是怎么優(yōu)化SQL的？

　　可以從這幾個(gè)維度回答這個(gè)問(wèn)題：

　　2.1.1、優(yōu)化表結(jié)構(gòu)

　　（1）盡量使用數(shù)字型字段

　　若只含數(shù)值信息的字段盡量不要設(shè)計(jì)為字符型，這會(huì)降低查詢和連接的性能，并會(huì)增加存儲(chǔ)開(kāi)銷。這是因?yàn)橐嬖谔幚聿樵兒瓦B接時(shí)會(huì)逐個(gè)比較字符串中每一個(gè)字符，而對(duì)于數(shù)字型而言只需要比較一次就夠了。

　　（2）盡可能的使用 varchar 代替 char

　　變長(zhǎng)字段存儲(chǔ)空間小，可以節(jié)省存儲(chǔ)空間。

　　（3）當(dāng)索引列大量重復(fù)數(shù)據(jù)時(shí)，可以把索引刪除掉

　　比如有一列是性別，幾乎只有男、女、未知，這樣的索引是無(wú)效的。

　　2.1.2、優(yōu)化查詢

　　應(yīng)盡量避免在 where 子句中使用!=或<>操作符

　　應(yīng)盡量避免在 where 子句中使用 or 來(lái)連接條件

　　任何查詢也不要出現(xiàn)select *

　　避免在 where 子句中對(duì)字段進(jìn)行 null 值判斷

　　2.1.3、索引優(yōu)化

　　對(duì)作為查詢條件和 order by的字段建立索引

　　避免建立過(guò)多的索引，多使用組合索引

　　2.2、怎么看執(zhí)行計(jì)劃（explain），如何理解其中各個(gè)字段的含義？

　　在 select 語(yǔ)句之前增加 explain 關(guān)鍵字，會(huì)返回執(zhí)行計(jì)劃的信息。

　　MySQL相關(guān)知識(shí)點(diǎn)有哪些

　　（1）id 列：是 select 語(yǔ)句的序號(hào)，MySQL將 select 查詢分為簡(jiǎn)單查詢和復(fù)雜查詢。

　　（2）select_type列：表示對(duì)應(yīng)行是是簡(jiǎn)單還是復(fù)雜的查詢。

　　（3）table 列：表示 explain 的一行正在訪問(wèn)哪個(gè)表。

　　（4）type 列：最重要的列之一。表示關(guān)聯(lián)類型或訪問(wè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 列：顯示查詢可能使用哪些索引來(lái)查找。

　　（6）key 列：這一列顯示 mysql 實(shí)際采用哪個(gè)索引來(lái)優(yōu)化對(duì)該表的訪問(wèn)。

　　（7）key_len 列：顯示了mysql在索引里使用的字節(jié)數(shù)，通過(guò)這個(gè)值可以算出具體使用了索引中的哪些列。

　　（8）ref 列：這一列顯示了在key列記錄的索引中，表查找值所用到的列或常量，常見(jiàn)的有：const（常量），func，NULL，字段名。

　　（9）rows 列：這一列是 mysql 估計(jì)要讀取并檢測(cè)的行數(shù)，注意這個(gè)不是結(jié)果集里的行數(shù)。

　　（10）Extra 列：顯示額外信息。比如有 Using index、Using where、Using temporary等。

　　2.3、關(guān)心過(guò)業(yè)務(wù)系統(tǒng)里面的sql耗時(shí)嗎？統(tǒng)計(jì)過(guò)慢查詢嗎？對(duì)慢查詢都怎么優(yōu)化過(guò)？

　　我們平時(shí)寫Sql時(shí)，都要養(yǎng)成用explain分析的習(xí)慣。慢查詢的統(tǒng)計(jì)，運(yùn)維會(huì)定期統(tǒng)計(jì)給我們

　　優(yōu)化慢查詢思路：

　　分析語(yǔ)句，是否加載了不必要的字段/數(shù)據(jù)

　　分析 SQL 執(zhí)行句話，是否命中索引等

　　如果 SQL 很復(fù)雜，優(yōu)化 SQL 結(jié)構(gòu)

　　如果表數(shù)據(jù)量太大，考慮分表

　　3、索引

　　3.1、聚集索引與非聚集索引的區(qū)別

　　可以按以下四個(gè)維度回答：

　　（1）一個(gè)表中只能擁有一個(gè)聚集索引，而非聚集索引一個(gè)表可以存在多個(gè)。

　　（2）聚集索引，索引中鍵值的邏輯順序決定了表中相應(yīng)行的物理順序；非聚集索引，索引中索引的邏輯順序與磁盤上行的物理存儲(chǔ)順序不同。

　　（3）索引是通過(guò)二叉樹(shù)的數(shù)據(jù)結(jié)構(gòu)來(lái)描述的，我們可以這么理解聚簇索引：索引的葉節(jié)點(diǎn)就是數(shù)據(jù)節(jié)點(diǎn)。而非聚簇索引的葉節(jié)點(diǎn)仍然是索引節(jié)點(diǎn)，只不過(guò)有一個(gè)指針指向?qū)?yīng)的數(shù)據(jù)塊。

　　（4）聚集索引：物理存儲(chǔ)按照索引排序；非聚集索引：物理存儲(chǔ)不按照索引排序；

　　3.2、為什么要用 B+ 樹(shù)，為什么不用普通二叉樹(shù)？

　　可以從幾個(gè)維度去看這個(gè)問(wèn)題，查詢是否夠快，效率是否穩(wěn)定，存儲(chǔ)數(shù)據(jù)多少，以及查找磁盤次數(shù)，為什么不是普通二叉樹(shù)，為什么不是平衡二叉樹(shù)，為什么不是B樹(shù)，而偏偏是 B+ 樹(shù)呢？

　　3.2.1、為什么不是普通二叉樹(shù)？

　　如果二叉樹(shù)特殊化為一個(gè)鏈表，相當(dāng)于全表掃描。平衡二叉樹(shù)相比于二叉查找樹(shù)來(lái)說(shuō)，查找效率更穩(wěn)定，總體的查找速度也更快。

　　3.2.2、為什么不是平衡二叉樹(shù)呢？

　　我們知道，在內(nèi)存比在磁盤的數(shù)據(jù)，查詢效率快得多。如果樹(shù)這種數(shù)據(jù)結(jié)構(gòu)作為索引，那我們每查找一次數(shù)據(jù)就需要從磁盤中讀取一個(gè)節(jié)點(diǎn)，也就是我們說(shuō)的一個(gè)磁盤塊，但是平衡二叉樹(shù)可是每個(gè)節(jié)點(diǎn)只存儲(chǔ)一個(gè)鍵值和數(shù)據(jù)的，如果是B樹(shù)，可以存儲(chǔ)更多的節(jié)點(diǎn)數(shù)據(jù)，樹(shù)的高度也會(huì)降低，因此讀取磁盤的次數(shù)就降下來(lái)啦，查詢效率就快啦。

　　3.2.3、為什么不是 B 樹(shù)而是 B+ 樹(shù)呢？

　　B+ 樹(shù)非葉子節(jié)點(diǎn)上是不存儲(chǔ)數(shù)據(jù)的，僅存儲(chǔ)鍵值，而B樹(shù)節(jié)點(diǎn)中不僅存儲(chǔ)鍵值，也會(huì)存儲(chǔ)數(shù)據(jù)。innodb中頁(yè)的默認(rèn)大小是16KB，如果不存儲(chǔ)數(shù)據(jù)，那么就會(huì)存儲(chǔ)更多的鍵值，相應(yīng)的樹(shù)的階數(shù)（節(jié)點(diǎn)的子節(jié)點(diǎn)樹(shù)）就會(huì)更大，樹(shù)就會(huì)更矮更胖，如此一來(lái)我們查找數(shù)據(jù)進(jìn)行磁盤的IO次數(shù)有會(huì)再次減少，數(shù)據(jù)查詢的效率也會(huì)更快。

　　B+ 樹(shù)索引的所有數(shù)據(jù)均存儲(chǔ)在葉子節(jié)點(diǎn)，而且數(shù)據(jù)是按照順序排列的，鏈表連著的。那么 B+ 樹(shù)使得范圍查找，排序查找，分組查找以及去重查找變得異常簡(jiǎn)單。

　　3.3、Hash 索引和 B+ 樹(shù)索引區(qū)別是什么？你在設(shè)計(jì)索引是怎么抉擇的？

　　B+ 樹(shù)可以進(jìn)行范圍查詢，Hash 索引不能。

　　B+ 樹(shù)支持聯(lián)合索引的最左側(cè)原則，Hash 索引不支持。

　　B+ 樹(shù)支持 order by 排序，Hash 索引不支持。

　　Hash 索引在等值查詢上比 B+ 樹(shù)效率更高。

　　B+ 樹(shù)使用 like 進(jìn)行模糊查詢的時(shí)候，like 后面（比如%開(kāi)頭）的話可以起到優(yōu)化的作用，Hash 索引根本無(wú)法進(jìn)行模糊查詢。

　　3.4、什么是最左前綴原則？什么是最左匹配原則？

　　最左前綴原則，就是最左優(yōu)先，在創(chuàng)建多列索引時(shí)，要根據(jù)業(yè)務(wù)需求，where 子句中使用最頻繁的一列放在最左邊。

　　當(dāng)我們創(chuàng)建一個(gè)組合索引的時(shí)候，如 (a1,a2,a3)，相當(dāng)于創(chuàng)建了（a1）、(a1,a2)和(a1,a2,a3)三個(gè)索引，這就是最左匹配原則。

　　3.5、索引不適合哪些場(chǎng)景?

　　數(shù)據(jù)量少的不適合加索引

　　更新比較頻繁的也不適合加索引 = 區(qū)分度低的字段不適合加索引（如性別）

　　3.6、索引有哪些優(yōu)缺點(diǎn)？

　　(1) 優(yōu)點(diǎn)：

　　唯一索引可以保證數(shù)據(jù)庫(kù)表中每一行的數(shù)據(jù)的唯一性

　　索引可以加快數(shù)據(jù)查詢速度，減少查詢時(shí)間

　　(2)缺點(diǎn)：

　　創(chuàng)建索引和維護(hù)索引要耗費(fèi)時(shí)間

　　索引需要占物理空間，除了數(shù)據(jù)表占用數(shù)據(jù)空間之外，每一個(gè)索引還要占用一定的物理空間

　　以表中的數(shù)據(jù)進(jìn)行增、刪、改的時(shí)候，索引也要?jiǎng)討B(tài)的維護(hù)。

　　4、鎖

　　4.1、MySQL 遇到過(guò)死鎖問(wèn)題嗎，你是如何解決的？

　　遇到過(guò)。我排查死鎖的一般步驟是醬紫的：

　　（1）查看死鎖日志 show engine innodb status;

　　（2）找出死鎖Sql

　　（3）分析sql加鎖情況

　　（4）模擬死鎖案發(fā)

　　（5）分析死鎖日志

　　（6）分析死鎖結(jié)果

　　4.2、說(shuō)說(shuō)數(shù)據(jù)庫(kù)的樂(lè)觀鎖和悲觀鎖是什么以及它們的區(qū)別？

　　（1）悲觀鎖：

　　悲觀鎖她專一且缺乏安全感了，她的心只屬于當(dāng)前事務(wù)，每時(shí)每刻都擔(dān)心著它心愛(ài)的數(shù)據(jù)可能被別的事務(wù)修改，所以一個(gè)事務(wù)擁有（獲得）悲觀鎖后，其他任何事務(wù)都不能對(duì)數(shù)據(jù)進(jìn)行修改啦，只能等待鎖被釋放才可以執(zhí)行。

　　（2）樂(lè)觀鎖：

　　樂(lè)觀鎖的“樂(lè)觀情緒”體現(xiàn)在，它認(rèn)為數(shù)據(jù)的變動(dòng)不會(huì)太頻繁。因此，它允許多個(gè)事務(wù)同時(shí)對(duì)數(shù)據(jù)進(jìn)行變動(dòng)。

　　實(shí)現(xiàn)方式：樂(lè)觀鎖一般會(huì)使用版本號(hào)機(jī)制或CAS算法實(shí)現(xiàn)。

　　4.3、MVCC 熟悉嗎，知道它的底層原理？

　　MVCC (Multiversion Concurrency Control)，即多版本并發(fā)控制技術(shù)。

　　MVCC在MySQL InnoDB中的實(shí)現(xiàn)主要是為了提高數(shù)據(jù)庫(kù)并發(fā)性能，用更好的方式去處理讀-寫沖突，做到即使有讀寫沖突時(shí)，也能做到不加鎖，非阻塞并發(fā)讀。

　　5、事務(wù)

　　5.1、MySQL事務(wù)得四大特性以及實(shí)現(xiàn)原理

　　原子性：事務(wù)作為一個(gè)整體被執(zhí)行，包含在其中的對(duì)數(shù)據(jù)庫(kù)的操作要么全部被執(zhí)行，要么都不執(zhí)行。

　　一致性：指在事務(wù)開(kāi)始之前和事務(wù)結(jié)束以后，數(shù)據(jù)不會(huì)被破壞，假如A賬戶給B賬戶轉(zhuǎn)10塊錢，不管成功與否，A和B的總金額是不變的。

　　隔離性：多個(gè)事務(wù)并發(fā)訪問(wèn)時(shí)，事務(wù)之間是相互隔離的，即一個(gè)事務(wù)不影響其它事務(wù)運(yùn)行效果。簡(jiǎn)言之，就是事務(wù)之間是進(jìn)水不犯河水的。

　　持久性：表示事務(wù)完成以后，該事務(wù)對(duì)數(shù)據(jù)庫(kù)所作的操作更改，將持久地保存在數(shù)據(jù)庫(kù)之中。

　　5.2、事務(wù)的隔離級(jí)別有哪些？MySQL的默認(rèn)隔離級(jí)別是什么？

　　讀未提交（Read Uncommitted）

　　讀已提交（Read Committed）

　　可重復(fù)讀（Repeatable Read）

　　串行化（Serializable）

　　Mysql默認(rèn)的事務(wù)隔離級(jí)別是可重復(fù)讀(Repeatable Read)

　　5.3、什么是幻讀，臟讀，不可重復(fù)讀呢？

　　事務(wù)A、B交替執(zhí)行，事務(wù)A被事務(wù)B干擾到了，因?yàn)槭聞?wù)A讀取到事務(wù)B未提交的數(shù)據(jù)，這就是臟讀。

　　在一個(gè)事務(wù)范圍內(nèi)，兩個(gè)相同的查詢，讀取同一條記錄，卻返回了不同的數(shù)據(jù)，這就是不可重復(fù)讀。

　　事務(wù)A查詢一個(gè)范圍的結(jié)果集，另一個(gè)并發(fā)事務(wù)B往這個(gè)范圍中插入/刪除了數(shù)據(jù)，并靜悄悄地提交，然后事務(wù)A再次查詢相同的范圍，兩次讀取得到的結(jié)果集不一樣了，這就是幻讀。

　　6、實(shí)戰(zhàn)

　　6.1、MySQL數(shù)據(jù)庫(kù)cpu飆升的話，要怎么處理呢？

　　排查過(guò)程：

　　（1）使用top 命令觀察，確定是mysqld導(dǎo)致還是其他原因。

　　（2）如果是mysqld導(dǎo)致的，show processlist，查看session情況，確定是不是有消耗資源的sql在運(yùn)行。

　　（3）找出消耗高的 sql，看看執(zhí)行計(jì)劃是否準(zhǔn)確，索引是否缺失，數(shù)據(jù)量是否太大。

　　處理：

　　（1）kill 掉這些線程(同時(shí)觀察 cpu 使用率是否下降)

　　（2）進(jìn)行相應(yīng)的調(diào)整(比如說(shuō)加索引、改 sql、改內(nèi)存參數(shù))

　　（3）重新跑這些 SQL。

　　其他情況：

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

　　6.2、MYSQL的主從延遲，你怎么解決？

　　主從復(fù)制分了五個(gè)步驟進(jìn)行：

　　步驟一：主庫(kù)的更新事件(update、insert、delete)被寫到binlog

　　步驟二：從庫(kù)發(fā)起連接，連接到主庫(kù)。

　　步驟三：此時(shí)主庫(kù)創(chuàng)建一個(gè)binlog dump thread，把binlog的內(nèi)容發(fā)送到從庫(kù)。

　　步驟四：從庫(kù)啟動(dòng)之后，創(chuàng)建一個(gè)I/O線程，讀取主庫(kù)傳過(guò)來(lái)的binlog內(nèi)容并寫入到relay log

　　步驟五：還會(huì)創(chuàng)建一個(gè)SQL線程，從relay log里面讀取內(nèi)容，從Exec_Master_Log_Pos位置開(kāi)始執(zhí)行讀取到的更新事件，將更新內(nèi)容寫入到slave的db

　　主從同步延遲的原因

　　一個(gè)服務(wù)器開(kāi)放Ｎ個(gè)鏈接給客戶端來(lái)連接的，這樣有會(huì)有大并發(fā)的更新操作, 但是從服務(wù)器的里面讀取binlog的線程僅有一個(gè)，當(dāng)某個(gè)SQL在從服務(wù)器上執(zhí)行的時(shí)間稍長(zhǎng) 或者由于某個(gè)SQL要進(jìn)行鎖表就會(huì)導(dǎo)致，主服務(wù)器的SQL大量積壓，未被同步到從服務(wù)器里。這就導(dǎo)致了主從不一致，也就是主從延遲。

　　主從同步延遲的解決辦法

　　主服務(wù)器要負(fù)責(zé)更新操作，對(duì)安全性的要求比從服務(wù)器要高，所以有些設(shè)置參數(shù)可以修改，比如sync_binlog=1，innodb_flush_log_at_trx_commit = 1 之類的設(shè)置等。

　　選擇更好的硬件設(shè)備作為slave。

　　把一臺(tái)從服務(wù)器當(dāng)度作為備份使用，而不提供查詢，那邊他的負(fù)載下來(lái)了，執(zhí)行relay log 里面的SQL效率自然就高了。

　　增加從服務(wù)器嘍，這個(gè)目的還是分散讀的壓力，從而降低服務(wù)器負(fù)載。

　　6.3、如果讓你做分庫(kù)與分表的設(shè)計(jì)，簡(jiǎn)單說(shuō)說(shuō)你會(huì)怎么做？

　　分庫(kù)分表方案:

　　水平分庫(kù)：以字段為依據(jù)，按照一定策略（hash、range等），將一個(gè)庫(kù)中的數(shù)據(jù)拆分到多個(gè)庫(kù)中。

　　水平分表：以字段為依據(jù)，按照一定策略（hash、range等），將一個(gè)表中的數(shù)據(jù)拆分到多個(gè)表中。

　　垂直分庫(kù)：以表為依據(jù)，按照業(yè)務(wù)歸屬不同，將不同的表拆分到不同的庫(kù)中。

　　垂直分表：以字段為依據(jù)，按照字段的活躍性，將表中字段拆到不同的表（主表和擴(kuò)展表）中。

　　常用的分庫(kù)分表中間件：

　　sharding-jdbc

　　Mycat

　　分庫(kù)分表可能遇到的問(wèn)題

　　事務(wù)問(wèn)題：需要用分布式事務(wù)啦

　　跨節(jié)點(diǎn)Join的問(wèn)題：解決這一問(wèn)題可以分兩次查詢實(shí)現(xiàn)

　　跨節(jié)點(diǎn)的count,order by,group by以及聚合函數(shù)問(wèn)題：分別在各個(gè)節(jié)點(diǎn)上得到結(jié)果后在應(yīng)用程序端進(jìn)行合并。

　　數(shù)據(jù)遷移，容量規(guī)劃，擴(kuò)容等問(wèn)題

　　ID問(wèn)題：數(shù)據(jù)庫(kù)被切分后，不能再依賴數(shù)據(jù)庫(kù)自身的主鍵生成機(jī)制啦，最簡(jiǎn)單可以考慮UUID

　　跨分片的排序分頁(yè)問(wèn)題

　　感謝你能夠認(rèn)真閱讀完這篇文章，希望小編分享的“MySQL相關(guān)知識(shí)點(diǎn)有哪些”這篇文章對(duì)大家有幫助。

（編輯：武林網(wǎng)）

上一篇：怎么了解mysql多表操作

下一篇：MySQL的binlog需如何恢復(fù)數(shù)據(jù)