溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
本篇內容主要講解“MySQL數據庫常見面試題有哪些”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“MySQL數據庫常見面試題有哪些”吧!
第一范式（1NF）：指表的列不可再分，數據庫中表的每一列都是不可分割的基本數據項，同一列中不能有多個值；
第二范式（2NF）：在 1NF 的基礎上，還包含兩部分的內容：一是表必須有一個主鍵；二是表中非主鍵列必須完全依賴于主鍵，不能只依賴于主鍵的一部分；
第三范式（3NF）：在 2NF 的基礎上，消除非主鍵列對主鍵的傳遞依賴，非主鍵列必須直接依賴于主鍵。
BC范式（BCNF）：在 3NF 的基礎上，消除主屬性對于碼部分的傳遞依賴
2.1、客戶端的數據庫驅動與數據庫連接池：
（1）客戶端與數據庫進行通信前，通過數據庫驅動與MySQL建立連接，建立完成之后，就發送SQL語句
（2）為了減少頻繁創建和銷毀連接造成系統性能的下降，通過數據庫連接池維護一定數量的連接線程，當需要進行連接時，就直接從連接池中獲取，使用完畢之后，再歸還給連接池。常見的數據庫連接池有 Druid、C3P0、DBCP
2.2、MySQL架構的Server層的執行過程：
（1）連接器：主要負責跟客戶端建立連接、獲取權限、維持和管理連接
（2）查詢緩存：優先在緩存中進行查詢，如果查到了則直接返回，如果緩存中查詢不到，在去數據庫中查詢。
MySQL緩存是默認關閉的，也就是說不推薦使用緩存，并且在MySQL8.0 版本已經將查詢緩存的整塊功能刪掉了。這主要是它的使用場景限制造成的：
先說下緩存中數據存儲格式：key（sql語句）- value（數據值），所以如果SQL語句（key）只要存在一點不同之處就會直接進行數據庫查詢了；
由于表中的數據不是一成不變的，大多數是經常變化的，而當數據庫中的數據變化了，那么相應的與此表相關的緩存數據就需要移除掉；
（3）解析器/分析器：分析器的工作主要是對要執行的SQL語句進行詞法解析、語法解析，最終得到抽象語法樹，然后再使用預處理器對抽象語法樹進行語義校驗，判斷抽象語法樹中的表是否存在，如果存在的話，在接著判斷select投影列字段是否在表中存在等。
（4）優化器：主要將SQL經過詞法解析、語法解析后得到的語法樹，通過數據字典和統計信息的內容，再經過一系列運算 ，最終得出一個執行計劃，包括選擇使用哪個索引
在分析是否走索引查詢時，是通過進行動態數據采樣統計分析出來；只要是統計分析出來的，那就可能會存在分析錯誤的情況，所以在SQL執行不走索引時，也要考慮到這方面的因素
（5）執行器：根據一系列的執行計劃去調用存儲引擎提供的API接口去調用操作數據，完成SQL的執行。
2.3、Innodb存儲引擎的執行過程：
（1）首先MySQL執行器根據 執行計劃 調用存儲引擎的API查詢數據
（2）存儲引擎先從緩存池buffer pool中查詢數據，如果沒有就會去磁盤中查詢，如果查詢到了就將其放到緩存池中
（3）在數據加載到 Buffer Pool 的同時，會將這條數據的原始記錄保存到 undo 日志文件中
（4）innodb 會在 Buffer Pool 中執行更新操作
（5）更新后的數據會記錄在 redo log buffer 中
（6）提交事務在提交的同時會做以下三件事
（7）（第一件事）將redo log buffer中的數據刷入到redo log文件中
（8）（第二件事）將本次操作記錄寫入到 bin log文件中
（9）（第三件事）將bin log文件名字和更新內容在 bin log 中的位置記錄到redo log中，同時在 redo log 最后添加 commit 標記
（10）使用一個后臺線程，它會在某個時機將我們Buffer Pool中的更新后的數據刷到 MySQL 數據庫中，這樣就將內存和數據庫的數據保持統一了
存儲引擎是對底層物理數據執行實際操作的組件，為Server服務層提供各種操作數據的API。常用的存儲引擎有InnoDB、MyISAM、Memory。這里我們主要介紹InnoDB 與 MyISAM 的區別：
（1）事務：MyISAM不支持事務，InnoDB支持事務
（2）鎖級別：MyISAM只支持表級鎖，InnoDB支持行級鎖和表級鎖，默認使用行級鎖，但是行鎖只有通過索引查詢數據才會使用，否則將使用表鎖。行級鎖在每次獲取鎖和釋放鎖的操作需要消耗比表鎖更多的資源。使用行鎖可能會存在死鎖的情況，但是表級鎖不存在死鎖
（3）主鍵和外鍵：MyISAM 允許沒有任何索引和主鍵的表存在，不支持外鍵。InnoDB的主鍵不能為空且支持主鍵自增長，如果沒有設定主鍵或者非空唯一索引，就會自動生成一個6字節的主鍵，支持外鍵完整性約束
（4）索引結構：MyISAM 和 InnoDB 都是使用B+樹索引，MyISAM的主鍵索引和輔助索引的Data域都是保存行數據記錄的地址。但是InnoDB的主鍵索引的Data域保存的不是行數據記錄的地址，而是保存該行的所有數據內容，而輔助索引的Data域保存的則是主索引的值。
由于InnoDB的輔助索引保存的是主鍵索引的值，所以使用輔助索引需要檢索兩遍索引：首先檢索輔助索引獲得主鍵，然后用主鍵到主索引中檢索獲得記錄。這也是為什么不建議使用過長的字段作為主鍵的原因：由于輔助索引包含主鍵列，所以，如果主鍵使用過長的字段，將會導致其他輔助索變得更大，所以爭取盡量把主鍵定義得小一些。
（5）全文索引：MyISAM支持全文索引，InnoDB在5.6版本之前不支持全文索引，5.6版本及之后的版本開始支持全文索引
（6）表的具體行數：
① MyISAM：保存有表的總行數，如果使用 select count() from table 會直接取出出該值，不需要進行全表掃描。
② InnoDB：沒有保存表的總行數，如果使用 select count() from table 需要會遍歷整個表，消耗相當大。
（7）存儲結構：
① MyISAM會在磁盤上存儲成三個文件：.frm文件存儲表定義，.MYD文件存儲數據，.MYI文件存儲索引。
② InnoDB：把數據和索引存放在表空間里面，所有的表都保存在同一個數據文件中，InnoDB表的大小只受限于操作系統文件的大小，一般為2GB。
（8）存儲空間：
① MyISAM：可被壓縮，存儲空間較小。支持三種不同的存儲格式：靜態表(默認，但是注意數據末尾不能有空格，會被去掉)、動態表、壓縮表。
② InnoDB：需要更多的內存和存儲，它會在主內存中建立其專用的緩沖池用于高速緩沖數據和索引。
（9）適用場景：
① 如果需要提供回滾、崩潰恢復能力的ACID事務能力，并要求實現行鎖級別并發控制，InnoDB是一個好的選擇；
② 如果數據表主要用來查詢記錄，讀操作遠遠多于寫操作且不需要數據庫事務的支持，則MyISAM引擎能提供較高的處理效率；
備注：在mysql8.0版本中已經廢棄了MyISAM存儲引擎
數據庫的事務是并發控制的基本單位，是指邏輯上的一組操作，要么全部執行，要么全部不執行。
4.1、事務的ACID：
（1）原子性：事務是一個不可分割的工作單元，事務里的操作要么都成功，要么都失敗，如果事務執行失敗，則需要進行回滾。
（2）隔離性：事務的所操作的數據在提交之前，對其他事務的可見程度。
（3）持久性：一旦事務提交，它對數據庫中數據的改變就是永久的。
（4）一致性：事務不能破壞數據的完整性和業務的一致性。例如在轉賬時，不管事務成功還是失敗，雙方錢的總額不變。
4.2、ACID的實現原理：
4.2.1、原子性：原子性是通過MySQL的回滾日志undo log來實現的：當事務對數據庫進行修改時，InnoDB會生成對應的undo log；如果事務執行失敗或調用了rollback，導致事務需要回滾，便可以利用undo log中的信息將數據回滾到修改之前的樣子。
4.2.2、隔離性：
（1）事務的隔離級別：
為保證在并發環境下讀取數據的完整性和一致性，數據庫提供了四種事務隔離級別，隔離級別越高，越能保證數據的完整性和一致性，但對高并發性能影響也越大，執行效率越低。（四種隔離級別從上往下依次升高）
讀未提交：允許事務在執行過程中，讀取其他事務尚未提交的數據；
讀已提交：允許事務在執行過程中讀取其他事務已經提交的數據；
可重復讀（默認級別）：在同一個事務內，任意時刻的查詢結果都是一致的；
讀序列化：所有事務逐個依次執行，每次讀都需要獲取表級共享鎖，讀寫會相互阻塞。
（2）事務的并發問題：
如果不考慮事務的隔離性，在事務并發的環境下，可能存在問題有：
更新丟失：兩個或多個事務操作相同的數據，然后基于選定的值更新該行時，由于每個事務都不知道其他事務的存在，就會發生丟失更新問題：最后的更新覆蓋了其他事務所做的更新。
臟讀：指事務A正在訪問數據，并且對數據進行了修改（事務未提交），這時，事務B也使用這個數據，后來事務A撤銷回滾，并把修改后的數據恢復原值，B讀到的數據就與數據庫中的數據不一致，即B讀到的數據是臟數據。
不可重復讀：在一個事務內，多次讀取同一個數據，但是由于另一個事務在此期間對這個數據做了修改并提交，導致前后讀取到的數據不一致；
幻讀：在一個事務中，先后兩次進行讀取相同的數據（一般是范圍查詢），但由于另一個事務新增或者刪除了數據，導致前后兩次結果不一致。
不同的事務隔離級別，在并發環境會存在不同的并發問題：
（3）事務隔離性的實現原理：
Innodb事務的隔離級別是由MVVC和鎖機制實現的：
① MVCC（Multi-Version Concurrency Control，多版本并發控制）是 MySQL 的 InnoDB 存儲引擎實現事務隔離級別的一種具體方式，用于實現讀已提交和可重復讀這兩種隔離級別。而讀未提交隔離級別總是讀取最新的數據行，無需使用 MVCC。讀序列化隔離級別需要對所有讀取的行都加鎖，單純使用 MVCC 無法實現。
MVCC是通過在每行記錄后面保存兩個隱藏的列來實現的，一個保存了行的事務ID，一個保存了行的回滾段指針。每開始一個新的事務，都會自動遞增產生一個新的事務ID。事務開始時會把該事務ID放到當前事務影響的行事務ID字段中，而回滾段的指針有該行記錄上的所有版本數據，在undo log回滾日志中通過鏈表形式組織，也就是說該值實際指向undo log中該行的歷史記錄鏈表。
在并發訪問數據庫時，對正在事務中的數據做MVCC多版本的管理，以避免寫操作阻塞讀操作，并且可以通過比較版本解決快照讀方式的幻讀問題，但對于當前讀的幻讀，MVCC并不能解決，需要通過臨鍵鎖來解決。
② 鎖機制：
MySQL鎖機制的基本工作原理就是：事務在修改數據庫之前，需要先獲得相應的鎖，獲得鎖的事務才可以修改數據；在該事務操作期間，這部分的數據是鎖定，其他事務如果需要修改數據，需要等待當前事務提交或回滾后釋放鎖。
排它鎖解決臟讀
共享鎖解決不可重復讀
臨鍵鎖解決幻讀
4.2.3、持久性：
持久性的依靠redo log日志實現，在執行SQL時會保存已執行的SQL語句到一個redo log文件，但是為了提高效率，將數據寫入到redo log之前，會先寫入到內存中的redo log buffer緩存區中。寫入過程如下：當向數據庫寫入數據時，執行過程會首先寫入redo log buffer，redo log buffer中修改的數據會定期刷新到磁盤的redo log文件中，這一過程稱為刷盤（即redo log buffer寫日志到磁盤的redo log file中 ）。
redo log buffer的使用可以大大提高了讀寫數據的效率，但是也帶了新的問題：如果MySQL宕機，而此時redo log buffer中修改的數據在內存還沒有刷新到磁盤，就會導致數據的丟失，事務的持久性無法保證。為了確保事務的持久性，在當事務提交時，會調用fsync接口對redo log進行刷盤 ，刷新頻率由 innodb_flush_log_at_trx_commit變量來控制的：
0：表示不刷入磁盤；
1：事務每次提交的時候，就把緩沖池中的數據刷新到磁盤中；
2：提交事務的時候，把緩沖池中的數據寫入磁盤文件對應的 os cache 緩存里去，而不是直接進入磁盤文件。可能 1 秒后才會把 os cache 里的數據寫入到磁盤文件里去。
4.2.4、一致性：
一致性指的是事務不能破壞數據的完整性和業務的一致性 ：
數據的完整性： 實體完整性、列完整性（如字段的類型、大小、長度要符合要求）、外鍵約束等
業務的一致性：例如在銀行轉賬時，不管事務成功還是失敗，雙方錢的總額不變。
當數據庫中多個事務并發存取同一數據的時候，若對并發操作不加控制就可能會讀取和存儲不正確的數據，破壞數據庫的一致性。MySQL鎖機制的基本工作原理就是，事務在修改數據庫之前，需要先獲得相應的鎖，獲得鎖的事務才可以修改數據；在該事務操作期間，這部分的數據是鎖定，其他事務如果需要修改數據，需要等待當前事務提交或回滾后釋放鎖。
按照不同的分類方式，鎖的種類可以分為以下幾種：
按鎖的粒度劃分：表級鎖、行級鎖、頁級鎖；
按鎖的類型劃分：共享（鎖S鎖）、排他鎖（X鎖）；
按鎖的使用策略劃分：樂觀鎖、悲觀鎖；
5.1、表級鎖、行級鎖、頁級鎖：
表級鎖：最大粒度的鎖級別，發生鎖沖突的概率最高，并發度最低，但開銷小，加鎖快，不會出現死鎖；
行級鎖：最小粒度的所級別，發生鎖沖突的概率最小，并發度最高，但開銷大，加鎖慢，會發生死鎖；
頁級鎖：鎖粒度界于表級鎖和行級鎖之間，對表級鎖和行級鎖的折中，并發度一般。開銷和加鎖時間也界于表鎖和行鎖之間，會出現死鎖；
不同的存儲引擎支持不同的鎖機制：
InnoDB存儲引擎支持行級鎖和表級鎖，默認情況下使用行級鎖，但只有通過索引進行查詢數據，才使用行級鎖，否就使用表級鎖。
MyISAM和MEMORY存儲引擎采用的是表級鎖；
BDB存儲引擎使用的是頁面鎖，但也支持表級鎖；
5.2、InnoDB的行鎖：
InnoDB的行鎖有兩種類型：
共享鎖（S鎖、讀鎖）：多個事務可以對同一數據行共享一把S鎖，但只能進行讀不能修改；
排它鎖（X鎖、寫鎖）：一個事務獲取排它鎖之后，可以對鎖定范圍內的數據行執行寫操作，在鎖定期間，其他事務不能再獲取這部分數據行的鎖（共享鎖、排它鎖），只允許獲取到排它鎖的事務進行更新數據。
對于update，delete，insert 操作，InnoDB會自動給涉及的數據行加排他鎖；對于普通SELECT語句，InnoDB不會加任何鎖。
5.3、InnoDB的表鎖與意向鎖：
因為InnoDB引擎允許行鎖和表鎖共存，實現多粒度的鎖機制，但是表鎖和行鎖雖然鎖定范圍不同，但是會相互沖突。當你要加表鎖時，勢必要先遍歷該表的所有記錄，判斷是否有排他鎖。這種遍歷檢查的方式顯然是一種低效的方式，MySQL引入了意向鎖，來檢測表鎖和行鎖的沖突。
意向鎖也是表級鎖，分為讀意向鎖（IS鎖）和寫意向鎖（IX鎖）。當事務要在記錄上加上行鎖時，則先在表上加上對應的意向鎖。之后事務如果想進行鎖表，只要先判斷是否有意向鎖存在，存在時則可快速返回該表不能啟用表鎖，否則就需要等待，提高效率。
5.4、InnoDB行鎖的實現與臨鍵鎖：
InnoDB的行鎖是通過給索引上的索引項加鎖來實現的。只有通過索引檢索數據，才能使用行鎖，否則將使用表鎖。
在InnoDB中，為了解決幻讀的現象，引入了臨鍵鎖(next-key)。根據索引，劃分為一個個左開右閉的區間。當進行范圍查詢的時候，若命中索引且能夠檢索到數據，則鎖住記錄所在的區間和它的下一個區間。其實，臨鍵鎖(Next-Key) = 記錄鎖(Record Locks) + 間隙鎖(Gap Locks)
間隙鎖：當使用范圍查詢而不是精準查詢進行檢索數據，并請求共享或排它鎖時，InnoDB會給符合范圍條件的已有數據記錄的索引項加鎖；對于鍵值在條件范圍內但并不存在的記錄，叫做間隙(GAP)。
記錄鎖：當使用唯一索引，且記錄存在的精準查詢時，使用記錄鎖
5.5、利用鎖機制解決并發問題：
X鎖解決臟讀
S鎖解決不可重復讀
臨鍵鎖解決幻讀
InnoDB存儲引擎鎖機制的詳細內容和MyISAM存儲引擎的鎖機制的詳細內容可以閱讀這篇文章：MySQL數據庫：鎖機制_張維鵬的博客-CSDN博客_數據庫中的鎖機制
索引本質上就是一種通過減少查詢需要遍歷行數，加快查詢性能的數據結構，避免數據庫進行全表掃描，好比書的目錄，讓你更快的找到內容。（一個表最多16個索引）
6.1、索引的優缺點：
（1）索引的優點：
減少查詢需要檢索的行數，加快查詢速度，避免進行全表掃描，這也是創建索引的最主要的原因。
如果索引的數據結構是B+樹，在使用分組和排序時，可以顯著減少查詢中分組和排序的時間。
通過創建唯一性索引，可以保證數據庫表中每一行數據的唯一性。
（2）索引的缺點：
當對表中的數據進行增加、刪除和修改時，索引也要進行更新，維護的耗時隨著數據量的增加而增加。
索引需要占用物理空間，如果要建立聚簇索引，那么需要的空間就會更大。
6.2、索引的使用場景：
（1）在哪些列上面創建索引：
WHERE子句中經常出現的列上面創建索引，加快條件的判斷速度。
按范圍存取的列或者在group by或order by中使用的列，因為索引已經排序，這樣可以利用索引加快排序查詢時間。
經常用于連接的列上，這些列主要是一些外鍵，可以加快連接的速度；
作為主鍵的列上，強制該列的唯一性和組織表中數據的排列結構；
（2）不在哪些列建索引？
區分度不高的列。由于這些列的取值很少，例如性別，在查詢的結果中，結果集的數據行占了表中數據行的很大比例，即需要在表中搜索的數據行的比例很大。增加索引，并不能明顯加快檢索速度。
在查詢中很少的列不應該創建索引。由于這些列很少使用到，但增加了索引，反而降低了系統的維護速度和增大了空間需求。
當添加索引造成修改成本的提高 遠遠大于 檢索性能的提高時，不應該創建索引。當增加索引時，會提高檢索性能，但是會降低修改性能。當減少索引時，會提高修改性能，降低檢索性能。
定義為text, image和bit數據類型的列不應該增加索引。這些列的數據量要么相當大，要么取值很少。
6.3、 索引的分類：
（1）普通索引、唯一索引、主鍵索引、全文索引、組合索引。
普通索引：最基本的索引，沒有任何限制
唯一索引：但索引列的值必須唯一，允許有空值，可以有多個NULL值。如果是組合索引，則列值的組合必須唯一。
主鍵索引：一種特殊的唯一索引，不允許有空值。
全文索引：全文索引僅可用于 MyISAM 表，并只支持從CHAR、VARCHAR或TEXT類型，用于替代效率較低的like 模糊匹配操作，而且可以通過多字段組合的全文索引一次性全模糊匹配多個字段。
組合索引：主要是為了提高mysql效率，創建組合索引時應該將最常用作限制條件的列放在最左邊，依次遞減。
（2）聚簇索引與非聚簇索引：
如果按數據存儲的物理順序與索引值的順序分類，可以將索引分為聚簇索引與非聚簇索引兩類：
聚簇索引：表中數據存儲的物理順序與索引值的順序一致，一個基本表最多只能有一個聚簇索引，更新聚簇索引列上的數據時，往往導致表中記錄的物理順序的變更，代價較大，因此對于經常更新的列不宜建立聚簇索引
非聚簇索引：表中數據的物理順序與索引值的順序不一致的索引組織，一個基本表可以有多個聚簇索引。
6.4、索引的數據結構：
常見的索引的數據結構有：B+Tree、Hash索引。
（1）Hash索引：MySQL中只有Memory存儲引擎支持hash索引，是Memory表的默認索引類型。hash索引把數據以hash值形式組織起來，因此查詢效率非常高，可以一次定位。
hash索引的缺點：
Hash索引僅能滿足等值的查詢，不能滿足范圍查詢、排序。因為數據在經過Hash算法后，其大小關系就可能發生變化。
當創建組合索引時，不能只使用組合索引的部分列進行查詢。因為hash索引是把多個列數據合并后再計算Hash值，所以對單獨列數據計算Hash值是沒有意義的。
當發生Hash碰撞時，Hash索引不能避免表數據的掃描。因為僅僅比較Hash值是不夠的，需要比較實際的值以判定是否符合要求。
（2）B+Tree索引：B+Tree是mysql使用最頻繁的一個索引數據結構，是Innodb和Myisam存儲引擎模式的索引類型。B+Tree索引在查找時需要從根節點到葉節點進行多次IO操作，在查詢速度比不上Hash索引，但是更適合排序等操作。
B+Tree索引的優點：
頁內節點不存儲內容，每次IO可以讀取更多的行，大大減少磁盤I/O讀取次數
帶順序訪問指針的B+Tree：B+Tree所有索引數據都存儲在葉子結點上，并且增加了順序訪問指針，每個葉子節點都有指向相鄰葉子節點的指針，這樣做是為了提高區間查詢效率。
6.5、為什么使用B+Tree作為索引：
索引本身也很大，不可能全部存儲在內存中，因此索引往往以索引文件的形式存儲在磁盤上。這樣的話，索引查找過程中就要產生磁盤I/O消耗，相對于內存存取，磁盤I/O存取的消耗要高幾個數量級，所以評價一個數據結構作為索引的優劣最重要的指標就是在查找過程中磁盤I/O操作次數的漸進復雜度。換句話說，索引的數據結構要盡量減少查找過程中磁盤I/O的存取次數。
（1）局部性原理與程序預讀：
由于磁盤本身存取就比主存慢很多，再加上機械運動耗費，因此為了提高效率，要盡量減少磁盤I/O。為了達到這個目的，磁盤往往不是嚴格按需讀取，而是每次都會預讀，即使只需要一個字節，磁盤也會從這個位置開始，順序向后讀取一定長度的數據放入內存。這樣做的理論依據是計算機科學中著名的局部性原理：當一個數據被用到時，其附近的數據也通常會馬上被使用。程序運行期間所需要的數據通常比較集中。
由于磁盤順序讀取的效率很高（不需要尋道時間，只需很少的旋轉時間），因此對于具有局部性的程序來說，預讀可以提高I/O效率。預讀的長度一般為頁的整倍數。當程序要讀取的數據不在主存中時，會觸發一個缺頁異常，此時系統會向磁盤發出讀盤信號，磁盤會找到數據的起始位置并向后連續讀取一頁或幾頁載入內存中，然后異常返回，程序繼續運行。
（2）B+Tree索引的性能分析：
上文說過一般使用磁盤I/O次數評價索引結構的優劣。我們先從B樹分析，B樹檢索一次最多需要訪問h個節點，同時，數據庫巧妙利用了磁盤預讀原理，將一個節點的大小設為等于一個頁，即每次新建節點時，直接申請一個頁的空間，這樣就保證一個節點在物理上也存儲在一個頁里，加之計算機存儲分配都是按頁對齊的，這樣就實現了每個節點只需要一次I/O就可以完全載入。B樹中一次檢索最多需要h-1次I/O（根節點常駐內存），時間復雜度為O(h)=O(logdN)。一般實際應用中，出度d是非常大的數字，通常超過100，因此h非常小。綜上所述，用B樹作為索引結構效率是非常高的。
而紅黑樹這種結構，雖然時間復雜度也為O(h)，但是h明顯要深的多，并且由于邏輯上很近的節點，在物理上可能很遠，無法利用局部性，所以IO效率明顯比B樹差很多。
另外，B+Tree更適合作為索引的數據結構，原因和內節點出度d有關。從上面分析可以看到，d越大索引的性能越好，而出度d的上限取決于節點內key和data的大小，由于B+Tree內節點去掉了data域，因此可以擁有更大的出度，磁盤IO的次數也就更少了。
（3）B+樹索引 和 B樹索引 的對比？
根據B-Tree 和 B+Tree的結構，我們可以發現B+樹相比于B樹，在文件系統或者數據庫系統當中，更有優勢，原因如下：
（1）B+樹有利于對數據庫的掃描：B樹在提高了磁盤IO性能的同時并沒有解決元素遍歷的效率低下的問題，而B+樹只需要遍歷葉子節點就可以解決對全部關鍵字信息的掃描，所以范圍查詢、排序等操作，B+樹有著更高的性能。
（2）B+樹的磁盤IO代價更低：B+樹的內部結點的data域并沒有存儲數據，因此其內部結點相對于B樹更小。如果把所有同一內部結點的關鍵字存放在同一盤塊中，那么盤塊所能容納的關鍵字數量也越多。一次性讀入內存中的需要查找的關鍵字也就越多，相對來說I/O讀寫次數也就降低了。
（3）B+樹的查詢效率更加穩定：由于B+樹的內部結點只是葉子結點中關鍵字的索引，并不存儲數據。所以任何關鍵字的查找必須走一條從根結點到葉子結點的路。所有關鍵字查詢的路徑長度相同，導致每一個數據的查詢效率相當。
（4）MySQL的 InnoDB 和 MyISAM 存儲引擎中B+Tree索引的實現？
MyISAM和InnoDB都是使用B+樹索引，MyISAM的主鍵索引和輔助索引的Data域都是保存行的地址，但是InnoDB的主鍵索引保存的不是行的地址，而是保存該行的所有所有數據，而輔助索引的Data域保存的則是主索引的值。
索引的長度限制：
對于 Innodb 的組合索引，如果各個列中的長度超過767字節的，則會對超過767字節的列取前綴索引；對于 Innodb 的單列索引，如果列的長度超過767的，則取前綴索引（取前255字符）
對于 MyISAM 的組合索引，所創建的索引長度和不能超過1000 bytes，否則會報錯，創建失敗；對于 MyISAM 的單列索引，最大長度也不能超過1000，否則會報警，但是創建成功，最終創建的是前綴索引（取前333個字符）
（1）MySQL的SQL優化和索引優化：https://blog.csdn.net/a745233700/article/details/84455241
（2）MySQL的表結構優化：https://blog.csdn.net/a745233700/article/details/84405087
MySQL屬于 IO 密集型的應用程序，主要職責就是數據的管理及存儲工作。而我們知道，從內存中讀取一個數據庫的時間是微秒級別，而從一塊普通硬盤上讀取一個IO是在毫秒級別，二者相差3個數量級。所以，要優化數據庫，首先第一步需要優化的就是 IO，盡可能將磁盤IO轉化為內存IO。所以對于MySQL數據庫的參數優化上，主要針對減少磁盤IO的參數做優化：比如使用 query_cache_size 調整查詢緩存的大小，使用 innodb_buffer_pool_size 調整緩沖區的大小；
執行計劃是SQL語句經過查詢分析器后得到的 抽象語法樹 和 相關表的統計信息 作出的一個查詢方案，這個方案是由查詢優化器自動分析產生的。由于是動態數據采樣統計分析出來的結果，所以可能會存在分析錯誤的情況，也就是存在執行計劃并不是最優的情況。通過explain關鍵字知道MySQL是如何執行SQL查詢語句的，分析select 語句的性能瓶頸，從而改進我們的查詢，explain的結果如下：
重要的有id、type、key、key_len、rows、extra：
（1）id：id列可以理解為SQL執行順序的標識，有幾個select 就有幾個id。
id值不同：id值越大優先級越高，越先被執行；
id值相同：從上往下依次執行；
id列為null：表示這是一個結果集，不需要使用它來進行查詢。
（2）select_type：查詢的類型，主要用于區分普通查詢、聯合查詢、子查詢等復雜的查詢；
（3）table：表示 explain 的一行正在訪問哪個表
（4）type：訪問類型，即MySQL決定如何查找表中的行。依次從好到差：system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL，除了all之外，其他的 type 類型都可以使用到索引，除了 index_merge 之外，其他的type只可以用到一個索引。一般要求type為 ref 級別，范圍查找需要達到 range 級別。
system：表中只有一條數據匹配（等于系統表），可以看成 const 類型的特例
const：通過索引一次就找到了，表示使用主鍵索引或者唯一索引
eq_ref：主鍵或者唯一索引中的字段被用于連接使用，只會返回一行匹配的數據
ref：普通索引掃描，可能返回多個符合查詢條件的行。
fulltext：全文索引檢索，全文索引的優先級很高，若全文索引和普通索引同時存在時，mysql不管代價，優先選擇使用全文索引。
ref_or_null：與ref方法類似，只是增加了null值的比較。
index_merge：表示查詢使用了兩個以上的索引，索引合并的優化方法，最后取交集或者并集，常見and ，or的條件使用了不同的索引。
unique_subquery：用于where中的in形式子查詢，子查詢返回不重復值唯一值；
index_subquery：用于in形式子查詢使用到了輔助索引或者in常數列表，子查詢可能返回重復值，可以使用索引將子查詢去重。
range：索引范圍掃描，常見于使用>,<,between ,in ,like等運算符的查詢中。
index：索引全表掃描，把索引樹從頭到尾掃描一遍；
all：遍歷全表以找到匹配的行（Index與ALL雖然都是讀全表，但index是從索引中讀取，而ALL是從硬盤讀取）
NULL：MySQL在優化過程中分解語句，執行時甚至不用訪問表或索引
（5）possible_keys：查詢時可能使用到的索引
（6）key：實際使用哪個索引來優化對該表的訪問
（7）key_len：實際上用于優化查詢的索引長度，即索引中使用的字節數。通過這個值，可以計算出一個多列索引里實際使用了索引的哪寫字段。
（8）ref：顯示哪個字段或者常量與key一起被使用
（9）rows：根據表統計信息及索引選用情況，大致估算此處查詢需要讀取的行數，不是精確值。
（10）extra：其他的一些額外信息
using index：使用覆蓋索引
using index condition：查詢的列未被索引覆蓋，where篩選條件使用了索引
using temporary：用臨時表保存中間結果，常用于 group by 和 order by 操作中，通常是因為 group by 的列上沒有索引，也有可能是因為同時有group by和order by，但group by和order by的列又不一樣，一般看到它說明查詢需要優化了
using filesort：MySQL有兩種方式對查詢結果進行排序，一種是使用索引，另一種是filesort（基于快排實現的外部排序，性能比較差），當數據量很大時，這將是一個CPU密集型的過程，所以可以通過建立合適的索引來優化排序的性能
對explain執行計劃詳請感興趣的讀者可以閱讀這篇文章：https://blog.csdn.net/a745233700/article/details/84335453
10.1、MySQL主從復制的原理：
Slave從Master獲取binlog二進制日志文件，然后再將日志文件解析成相應的SQL語句在從服務器上重新執行一遍主服務器的操作，通過這種方式來保證數據的一致性。由于主從復制的過程是異步復制的，因此Slave和Master之間的數據有可能存在延遲的現象，只能保證數據最終的一致性。在master和slave之間實現整個復制過程主要由三個線程來完成：
（1）Slave SQL thread線程：創建用于讀取relay log中繼日志并執行日志中包含的更新，位于slave端
（2）Slave I/O thread線程：讀取 master 服務器Binlog Dump線程發送的內容并保存到slave服務器的relay log中繼日志中，位于slave端：
（3）Binlog dump thread線程(也稱為IO線程)：將bin-log二進制日志中的內容發送到slave服務器，位于master端
注意：如果一臺主服務器配兩臺從服務器那主服務器上就會有兩個Binlog dump 線程，而每個從服務器上各自有兩個線程；
10.2、主從復制流程：
（1）master服務器在執行SQL語句之后，記錄在binlog二進制文件中；
（2）slave端的IO線程連接上master端，并請求從指定bin log日志文件的指定pos節點位置（或者從最開始的日志）開始復制之后的日志內容。
（3）master端在接收到來自slave端的IO線程請求后，通知負責復制進程的IO線程，根據slave端IO線程的請求信息，讀取指定binlog日志指定pos節點位置之后的日志信息，然后返回給slave端的IO線程。該返回信息中除了binlog日志所包含的信息之外，還包括本次返回的信息在master端的binlog文件名以及在該binlog日志中的pos節點位置。
（4）slave端的IO線程在接收到master端IO返回的信息后，將接收到的binlog日志內容依次寫入到slave端的relay log文件的最末端，并將讀取到的master端的binlog文件名和pos節點位置記錄到master-info文件中（該文件存slave端），以便在下一次同步的候能夠告訴master從哪個位置開始進行數據同步；
（5）slave端的SQL線程在檢測到relay log文件中新增內容后，就馬上解析該relay log文件中的內容，然后還原成在master端真實執行的那些SQL語句，再按順序依次執行這些SQL語句，從而到達master端和slave端的數據一致性；
10.3、主從復制的好處：
（1）讀寫分離，通過動態增加從服務器來提高數據庫的性能，在主服務器上執行寫入和更新，在從服務器上執行讀功能。
（2）提高數據安全，因為數據已復制到從服務器，從服務器可以終止復制進程，所以，可以在從服務器上備份而不破壞主服務器相應數據。
（3）在主服務器上生成實時數據，而在從服務器上分析這些數據，從而提高主服務器的性能。
10.4、MySQL支持的復制類型及其優缺點：
binlog日志文件有兩種格式，一種是Statement-Based（基于語句的復制），另一種是Row-Based（基于行的復制）。默認格式為Statement-Based，如果想改變其格式在開啟服務的時候使用 -binlog-format 選項，其具體命令如下：
mysqld_safe –user=msyql –binlog-format=格式 &
（1）基于語句的復制（Statement-Based）：在主服務器上執行的SQL語句，在從服務器上執行同樣的語句。效率比較高。 一旦發現沒法精確復制時，會自動選著基于行的復制。
優點：
① 因為記錄的SQL語句，所以占用更少的存儲空間。binlog日志包含了描述數據庫操作的事件，但這些事件包含的情況只是對數據庫進行改變的操作，例如 insert、update、create、delete等操作。相反對于select、desc等類似的操作并不會去記錄。
② binlog日志文件記錄了所有的改變數據庫的語句，所以此文件可以作為數據庫的審核依據。
缺點：
① 不安全，不是所有的改變數據的語句都會被記錄。對于非確定性的行為不會被記錄。例如：對于 delete 或者 update 語句，如果使用了 limit 但是并沒有 order by ，這就屬于非確定性的語句，就不會被記錄。
② 對于沒有索引條件的update，insert……select 語句，必須鎖定更多的數據，降低了數據庫的性能。
（2）基于行的復制（Row-Based）：把改變的內容復制過去，而不是把命令在從服務器上執行一遍，從mysql5.0開始支持；
優點：
① 所有的改變都會被復制，這是最安全的復制方式；
② 對于 update、insert……select等語句鎖定更少的行；
缺點：
① 不能通過binlog日志文件查看什么語句執行了，也無從知道在從服務器上接收到什么語句，我們只能看到什么數據改變。
② 因為記錄的是數據，所以說binlog日志文件占用的存儲空間要比Statement-based大。
③ 對于數據量大的操作其花費的時間有更長。
（3）混合類型的復制：默認采用基于語句的復制，一旦發現基于語句的無法精確的復制時，就會采用基于行的復制。
有關主從復制更詳細的內容，請閱讀這篇文章：https://blog.csdn.net/a745233700/article/details/85256818
11.1、實現原理：
讀寫分離解決的是，數據庫的寫操作，影響了查詢的效率，適用于讀遠大于寫的場景。讀寫分離的實現基礎是主從復制，主數據庫利用主從復制將自身數據的改變同步到從數據庫集群中，然后主數據庫負責處理寫操作（當然也可以執行讀操作），從數據庫負責處理讀操作，不能執行寫操作。并可以根據壓力情況，部署多個從數據庫提高讀操作的速度，減少主數據庫的壓力，提高系統總體的性能。
11.2、讀寫分離提高性能的原因：
（1）增加物理服務器，負荷分攤；
（2）主從只負責各自的寫和讀，極大程度的緩解X鎖和S鎖爭用；
（3）從庫可配置MyISAM引擎，提升查詢性能以及節約系統開銷；
（4）主從復制另外一大功能是增加冗余，提高可用性，當一臺數據庫服務器宕機后能通過調整另外一臺從庫來以最快的速度恢復服務。
11.3、Mysql讀寫分寫的實現方式：
（1）基于程序代碼內部實現：在代碼中根據select 、insert進行路由分類。優點是性能較好，因為程序在代碼中實現，不需要增加額外的硬件開支，缺點是需要開發人員來實現，運維人員無從下手。
（2）基于中間代理層實現：代理一般介于應用服務器和數據庫服務器之間，代理數據庫服務器接收到應用服務器的請求后根據判斷后轉發到后端數據庫，有以下代表性的代理層。
讀寫分離解決的是數據庫讀寫操作的壓力，但是沒有分散數據庫的存儲壓力，利用分庫分表可以解決數據庫的儲存瓶頸，并提升數據庫的查詢效率。
12.1、垂直拆分：
（1）垂直分表：將一個表按照字段分成多個表，每個表存儲其中一部分字段。一般會將常用的字段放到一個表中，將不常用的字段放到另一個表中。
優點：
（1）避免IO競爭減少鎖表的概率。因為大的字段效率更低，第一，大字段占用的空間更大，單頁內存儲的行數變少，會使得IO操作增多；第二數據量大，需要的讀取時間長。
（2）可以更好地提升熱門數據的查詢效率。
（2）垂直分庫：按照業務模塊的不同，將表拆分到不同的數據庫中，適合業務之間的耦合度非常低、業務邏輯清晰的系統。
優點：
降低業務中的耦合，方便對不同的業務進行分級管理
可以提升IO、數據庫連接數、解決單機硬件存儲資源的瓶頸問題
（3）垂直拆分（分庫、分表）的缺點：
主鍵出現冗余，需要管理冗余列
事務的處理變得復雜
仍然存在單表數據量過大的問題
12.2、水平拆分：
（1）水平分表：在同一個數據庫內，把同一個表的數據按照一定規則拆分到多個表中。
優點：
解決了單表數據量過大的問題
避免IO競爭并減少鎖表的概率
（2）水平分庫：把同一個表的數據按照一定規則拆分到不同的數據庫中，不同的數據庫可以放到不同的服務器上。
優點：
解決了單庫大數據量的瓶頸問題
IO沖突減少，鎖的競爭減少，某個數據庫出現問題不影響其他數據庫，提高了系統的穩定性和可用性
（3）水平拆分（分表、分庫）的缺點：
分片事務一致性難以解決
跨節點JOIN性能差，邏輯會變得復雜
數據擴展難度大，不易維護
12.3、分庫分表存在的問題的解決：
（1）事務的問題：
① 方案一：使用分布式事務：
優點：由數據庫管理，簡單有效。
缺點：性能代價高，特別是shard越來越多。
② 方案二：程序與數據庫共同控制實現，原理就是將一個跨多個數據庫的分布式事務分解成多個僅存在于單一數據庫上面的小事務，并交由應用程序來總體控制各個小事務。
優點：性能上有優勢；
缺點：需要在應用程序在事務上做靈活控制。如果使用了spring的事務管理，改動起來會面臨一定的困難。
（2）跨節點 Join 的問題：
解決該問題的普遍做法是分兩次查詢實現：在第一次查詢的結果集中找出關聯數據的id，根據這些id發起第二次請求得到關聯數據。
（3）跨節點count，order by，group by，分頁和聚合函數問題：
由于這類問題都需要基于全部數據集合進行計算。多數的代理都不會自動處理合并工作，解決方案：與解決跨節點join問題的類似，分別在各個節點上得到結果后在應用程序端進行合并。和 join 不同的是每個結點的查詢可以并行執行，因此速度要比單一大表快很多。但如果結果集很大，對應用程序內存的消耗是一個問題。
12.4、分庫分表后，ID鍵如何處理？
分庫分表后不能每個表的ID都是從1開始，所以需要一個全局ID，設置全局ID主要有以下幾種方法：
（1）UUID：
優點：本地生成ID，不需要遠程調用，全局唯一不重復。
缺點：占用空間大，不適合作為索引。
（2）數據庫自增ID：在分庫分表表后使用數據庫自增ID，需要一個專門用于生成主鍵的庫，每次服務接收到請求，先向這個庫中插入一條沒有意義的數據，獲取一個數據庫自增的ID，利用這個ID去分庫分表中寫數據。
優點：簡單易實現。
缺點：在高并發下存在瓶頸。
（3）Redis生成ID：
優點：不依賴數據庫，性能比較好。
缺點：引入新的組件會使得系統復雜度增加
（4）Twitter的snowflake算法：是一個64位的long型的ID，其中有1bit是不用的，41bit作為毫秒數，10bit作為工作機器ID，12bit作為序列號。
1bit：第一個bit默認為0，因為二進制中第一個bit為1的話為負數，但是ID不能為負數.
41bit：表示的是時間戳，單位是毫秒。
10bit：記錄工作機器ID，其中5個bit表示機房ID，5個bit表示機器ID。
12bit：用來記錄同一毫秒內產生的不同ID。
（5）美團的Leaf分布式ID生成系統，美團點評分布式ID生成系統：
分區就是將表的數據按照特定規則存放在不同的區域，也就是將表的數據文件分割成多個小塊，在查詢數據的時候，只要知道數據數據存儲在哪些區域，然后直接在對應的區域進行查詢，不需要對表數據進行全部的查詢，提高查詢的性能。同時，如果表數據特別大，一個磁盤磁盤放不下時，我們也可以將數據分配到不同的磁盤去，解決存儲瓶頸的問題，利用多個磁盤，也能夠提高磁盤的IO效率，提高數據庫的性能。在使用分區表時，需要注意分區字段必須放在主鍵或者唯一索引中、每個表最大分區數為1024；常見的分區類型有：Range分區、List分區、Hash分區、Key分區，
（1）Range分區：按照連續的區間范圍進行分區
（2）List分區：按照給定的集合中的值進行選擇分區。
（3）Hash分區：基于用戶定義的表達式的返回值進行分區，該表達式使用將要插入到表中的這些行的列值進行計算。這個函數可以包含MySQL中有效的、產生非負整數值的任何表達式。
（4）Key分區：類似于按照HASH分區，區別在于Key分區只支持計算一列或多列，且key分區的哈希函數是由 MySQL 服務器提供。
（1）表分區的優點：
① 可伸縮性：
將分區分在不同磁盤，可以解決單磁盤容量瓶頸問題，存儲更多的數據，也能解決單磁盤的IO瓶頸問題。
② 提升數據庫的性能：
減少數據庫檢索時需要遍歷的數據量，在查詢時只需要在數據對應的分區進行查詢。
避免Innodb的單個索引的互斥訪問限制
對于聚合函數，例如sum()和count()，可以在每個分區進行并行處理，最終只需要統計所有分區得到的結果
③ 方便對數據進行運維管理：
方便管理，對于失去保存意義的數據，通過刪除對應的分區，達到快速刪除的作用。比如刪除某一時間的歷史數據，直接執行truncate，或者直接drop整個分區，這比detele刪除效率更高；
在某些場景下，單個分區表的備份很恢復會更有效率。
（1）自增ID：
使用自增ID的好處：
字段長度較 UUID 會小很多。
數據庫自動編號，按順序存放，利于檢索
無需擔心主鍵重復問題
使用自增ID的缺點：
因為是自增，在某些業務場景下，容易被其他人查到業務量。
發生數據遷移時，或者表合并時會非常麻煩
在高并發的場景下，競爭自增鎖會降低數據庫的吞吐能力
（2）UUID：通用唯一標識碼，UUID是基于當前時間、計數器和硬件標識等數據計算生成的。
使用UUID的優點：
唯一標識，不用考慮重復問題，在數據拆分、合并時也能達到全局的唯一性。
可以在應用層生成，提高數據庫的吞吐能力。
無需擔心業務量泄露的問題。
使用UUID的缺點：
因為UUID是隨機生成的，所以會發生隨機IO，影響插入速度，并且會造成硬盤的使用率較低。
UUID占用空間較大，建立的索引越多，造成的影響越大。
UUID之間比較大小較自增ID慢不少，影響查詢速度。
一般情況下，MySQL推薦使用自增ID，因為在MySQL的 InnoDB 存儲引擎中，主鍵索引是聚簇索引，主鍵索引的B+樹的葉子節點按照順序存儲了主鍵值及數據，如果主鍵索引是自增ID，只需要按順序往后排列即可，如果是UUID，ID是隨機生成的，在數據插入時會造成大量的數據移動，產生大量的內存碎片，造成插入性能的下降。
視圖是從一個或者多個表（或視圖）導出的表，其內容由查詢定義。視圖是一個虛擬表，數據庫中只存儲視圖的定義，不存儲視圖對應的數據，在對視圖的數據進行操作時，系統根據視圖的定義去操作相應的基本表。可以說，視圖是在基本表之上建立的表，它的結構和內容都來自基本表，依據基本表存在而存在。一個視圖可以對應一個基本表，也可以對應多個基本表。視圖是基本表的抽象和在邏輯意義上建立的新關系。
（1）視圖的優點：
簡化了操作，把經常使用的數據定義為視圖
安全性，用戶只能查詢和修改能看到的數據
邏輯上的獨立性，屏蔽了真實表的結構帶來的影響
（2）視圖的缺點：
性能差，數據庫必須把對視圖的查詢轉化成對基本表的查詢，如果這個視圖是由一個復雜的多表查詢所定義，那么，即使是視圖的一個簡單查詢，數據庫也要把它變成一個復雜的結合體，需要花費一定的時間。
SQL語句需要先編譯然后執行，而存儲過程就是一組為了完成特定功能的SQL語句集，經過編譯后存儲在數據庫中，用戶通過制定存儲過程的名字并給定參數來調用它。
用程序也可以實現操作數據庫的復雜邏輯，那為什么需要存儲過程呢？主要是因為使用程序調用API執行，其效率相對較慢，應用程序需通過引擎把SQL語句交給MYSQL引擎來執行，那還不如直接讓MySQL負責它最精通最能夠完成的工作。
存儲過程的優點：
（1）標準組件式編程：存儲過程創建后，可以在程序中被多次調用，而不必重新編寫該存儲過程的SQL語句。并且DBA可以隨時對存儲過程進行修改，對應用程序源代碼毫無影響。
（2）更快的執行速度：如果某一操作包含大量的Transaction-SQL代碼或分別被多次執行，那么存儲過程要比批處理的執行速度快很多。因為存儲過程是預編譯的，在首次運行一個存儲過程時查詢，優化器對其進行分析優化，并且給出最終被存儲在系統表中的執行計劃。而批處理的Transaction-SQL語句在每次運行時都要進行編譯和優化，速度相對要慢一些。
（3）增強SQL語言的功能和靈活性：存儲過程可以用控制語句編寫，有很強的靈活性，可以完成復雜的判雜的斷和較復運算。
（4）減少網絡流量：針對同一個數據庫對象的操作（如查詢、修改），如果這一操作所涉及的Transaction-SQL語句被組織進存儲過程，那么當在客戶計算機上調用該存儲過程時，網絡中傳送的只是該調用語句，從而大大減少網絡流量并降低了網絡負載。
（5）作為一種安全機制來充分利用：通過對執行某一存儲過程的權限進行限制，能夠實現對相應的數據的訪問權限的限制，避免了非授權用戶對數據的訪問，保證了數據的安全。
觸發器是與表有關的數據庫對象，當觸發器所在表上出現指定事件并滿足定義條件的時候，將執行觸發器中定義的語句集合。觸發器的特性可以應用在數據庫端確保數據的完整性。觸發器是一個特殊的存儲過程，不同的是存儲過程要用call來調用，而觸發器不需要使用call，也不需要手工調用，它在插入，刪除或修改特定表中的數據時觸發執行，它比數據庫本身標準的功能有更精細和更復雜的數據控制能力。
游標，就是游動的標識，可以充當指針的作用，使用游標可以遍歷查詢數據庫返回的結果集中的所有記錄，但是每次只能提取一條記錄，即每次只能指向并取出一行的數據，以便進行相應的操作。當你沒有使用游標的時候，相當于別人一下給你所有的東西讓你拿走；用了游標之后，相當于別人一件一件的給你，這時你可以先看看這個東西好不好，再自己進行選擇。
到此，相信大家對“MySQL數據庫常見面試題有哪些”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
