最近在複習 MySQL，感覺知識點很零散，順便鞏固總結下相關的知識。
1.事務四個特性：
面試常客，再基礎不過
- A 原子性（Atomicity）
- C 一致性（Consistency）
- I 隔離性（Isolation）
- D 持久性（Durability）
2.併發事務帶來的問題（要理解每個概念）
- 髒讀
- 丟失修改
- 不可重複讀
- 幻讀
3.事務隔離級別有哪些
- READ-UNCOMMITTED(讀取未提交)： 最低的隔離級別，允許讀取尚未提交的數據變更，可能會導致髒讀、幻讀或不可重複讀。
- READ-COMMITTED(讀取已提交)： 允許讀取併發事務已經提交的數據，可以阻止髒讀，但是幻讀或不可重複讀仍有可能發生。
- REPEATABLE-READ(可重複讀)： 對同一字段的多次讀取結果都是一致的，除非數據是被本身事務自己所修改，可以阻止髒讀和不可重複讀，但幻讀仍有可能發生。（MySQL默認的事務隔離級別）
- SERIALIZABLE(可串行化)： 最高的隔離級別，完全服從ACID的隔離級別。所有的事務依次逐個執行，這樣事務之間就完全不可能產生干擾，也就是說，該級別可以防止髒讀、不可重複讀以及幻讀。
3.MyISAM和InnoDB區別
MyISAM是MySQL的默認數據庫引擎（5.5版之前）。但MyISAM不支持事務和行級鎖，而且最大的缺陷就是崩潰後無法安全恢復。不過，5.5版本之後，MySQL引入了InnoDB（事務性數據庫引擎），MySQL 5.5版本後默認的存儲引擎爲InnoDB。
大多數時候我們使用的都是 InnoDB 存儲引擎，但是在某些情況下使用 MyISAM 也是合適的比如讀密集的情況下。（如果你不介意 MyISAM 崩潰回覆問題的話）。
二者區別：
- MyISAM 不支持外鍵，而 InnoDB 支持
- MyISAM 是非事務安全型的，而 InnoDB 是事務安全型的。
- MyISAM 鎖的粒度是表級，而 InnoDB 支持行級鎖定。
- MyISAM 支持全文類型索引，而 InnoDB 不支持全文索引。
- MyISAM 相對簡單，所以在效率上要優於 InnoDB，小型應用可以考慮使用 MyISAM。
- MyISAM 表是保存成文件的形式，在跨平臺的數據轉移中使用 MyISAM 存儲會省去不少的麻煩。
- InnoDB 表比 MyISAM 表更安全，可以在保證數據不會丟失的情況下，切換非事務表到事務表（alter table tablename type=innodb）。
鎖的區別:
- InnoDB(默認) ：事務優先 （適合高併發操作；行鎖）
- MyISAM ：性能優先 （表鎖）
應用場景:
- MyISAM 管理非事務表。它提供高速存儲和檢索，以及全文搜索能力。如果應用中需要執行大量的 SELECT 查詢，那麼 MyISAM 是更好的選擇。
- InnoDB 用於事務處理應用程序，具有衆多特性，包括 ACID 事務支持。如果應用中需要執行大量的 INSERT 或 UPDATE 操作，則應該使用 InnoDB，這樣可以提高多用戶併發操作的性能。
4.B樹和B+樹有什麼區別？爲什麼索引不用B樹？
B-樹
是一種平衡的多路查找(又稱排序)樹，就是B樹，在文件系統中有所應用。主要用作文件的索引。其中的B就表示平衡(Balance)
- B-樹 ：
-
定義任意非葉子結點最多隻有M個兒子；且M>2；
-
根結點的兒子數爲[2, M]；
-
除根結點以外的非葉子結點的兒子數爲[M/2, M]；
-
每個結點存放至少M/2-1（取上整）和至多M-1個關鍵字；（至少2個關鍵字）
-
非葉子結點的指針：P[1], P[2], …, P[M]；其中P[1]指向關鍵字小於K[1]的子樹，P[M]指向關鍵字大於K[M-1]的子樹，其它P[i]指向關鍵字屬於(K[i-1], K[i])的子樹；
-
所有葉子結點位於同一層；
（圖片來自網上，侵刪）
![]()
B-樹的搜索：從根結點開始，對結點內的關鍵字（有序）序列進行二分查找，如果命中則結束，否則進入查詢關鍵字所屬範圍的兒子結點；重複，直到所對應的兒子指針爲空，或已經是葉子結點；其搜索的特點：
-
關鍵字集合分佈在整顆樹中；
-
任何一個關鍵字出現且只出現在一個結點中；
-
搜索有可能在非葉子結點結束；
-
其搜索性能等價於在關鍵字全集內做一次二分查找；
-
由於限制了除根結點以外的非葉子結點，至少含有M/2個兒子，確保了結點的至少利用率，其最低搜索性能爲lgN；
-
B-樹的性能總是等價於二分查找（與M值無關），沒有B樹平衡的問題；
B+樹
性質：B+樹是B-樹的變體，也是一種多路搜索樹：
-
其定義基本與B-樹同，有以下不同點：
-
非葉子結點的子樹指針與關鍵字個數相同；
-
非葉子結點的子樹指針P[i]，指向關鍵字值屬於[K[i], K[i+1])的子樹（B-樹是開區間）；
-
爲所有葉子結點增加一個鏈指針；
-
所有關鍵字都在葉子結點出現；
B+的搜索與B-樹也基本相同，區別是B+樹只有達到葉子結點才命中（B-樹可以在
非葉子結點命中），其性能也等價於在關鍵字全集做一次二分查找；
（圖片來自網上，侵刪）
B+的特性：
-
所有關鍵字都出現在葉子結點的鏈表中（稠密索引），且鏈表中的關鍵字恰好是有序的；
-
不可能在非葉子結點命中；
-
非葉子結點相當於是葉子結點的索引（稀疏索引），葉子結點相當於是存儲（關鍵字）數據的數據層；
-
更適合文件索引系統；
5.數據庫的索引有什麼作用？
優點：
- 提高查詢效率（降低IO使用率）
- 降低CPU使用率 （…order by age desc，因爲 B樹索引 本身就是一個 好排序的結構，因此在排序時 可以直接使用）
缺點：
- 索引本身很大， 實際上索引也是一張表，該表保存了主鍵與索引字段，並指向實體表的記錄，所以索引列也是要佔用空間的；
- 索引在以下情況不適用： a. 少量數據，b.頻繁更新的字段，c.很少使用的字段
- 索引會降低增刪改的效率；MySQL不僅要保存數據，還要保存一下索引文件每次更新添加了索引列的字段， 都會調整因爲更新所帶來的鍵值變化後的索引信息。
6.樂觀鎖和悲觀鎖區別：
-
樂觀鎖：樂觀鎖的特點先進行業務操作，不到萬不得已不去拿鎖。即“樂觀”的認爲拿鎖多半是會成功的，因此在進行完業務操作需要實際更新數據的最後一步再去拿一下鎖就好。樂觀鎖是否在事務中其實是無所謂的。
-
悲觀鎖：悲觀鎖的特點是先獲取鎖，再進行業務操作，即“悲觀”的認爲獲取鎖是非常有可能失敗的，因此要先確保獲取鎖成功再進行業務操作。通常來講在數據庫上的悲觀鎖需要數據庫本身提供支持，即通過常用的select … for update操作來實現悲觀鎖。當數據庫執行select for update時會獲取被select中的數據行的行鎖，因此其他併發執行的select for update如果試圖選中同一行則會發生排斥（需要等待行鎖被釋放），因此達到鎖的效果。select for update獲取的行鎖會在當前事務結束時自動釋放，因此必須在事務中使用。
區別：
樂觀鎖在不發生取鎖失敗的情況下開銷比悲觀鎖小，但是一旦發生失敗回滾開銷則比較大，因此適合用在取鎖失敗概率比較小的場景，可以提升系統併發性能。
樂觀鎖還適用於一些比較特殊的場景，例如在業務操作過程中無法和數據庫保持連接等悲觀鎖無法適用的地方。
7.一條sql語句在mysql中如何執行的
- MySQL 主要分爲 Server 層和引擎層，Server 層主要包括連接器、查詢緩存、分析器、優化器、執行器，同時還有一個日誌模塊（binlog），這個日誌模塊所有執行引擎都可以共用,redolog 只有 InnoDB 有。
- 引擎層是插件式的，目前主要包括，MyISAM,InnoDB,Memory 等。
- 查詢語句的執行流程如下：權限校驗（如果命中緩存）—》查詢緩存—》分析器—》優化器—》權限校驗—》執行器—》引擎
- 更新語句執行流程如下：分析器----》權限校驗----》執行器—》引擎—redo log(prepare 狀態—》binlog—》redo log(commit狀態)
參考一條sql語句在mysql中如何執行的