文章目錄

• 一 存儲引擎
• • 1 MyISAM 與 InnoDB 的差異
  • 2 表級鎖與行級鎖
• 二 索引
• • 1 主鍵索引與二級索引
  • 2 聚簇索引與非聚簇索引
  • 3 數據結構：哈希表
  • 4 數據結構：B樹
  • 5 數據結構：B+樹
  • 6 數據結構：跳表
  • 7 為什么不使用紅黑樹**
  • 8 為什么不使用B樹**
• 三 MySQL 事務
• • 1 ACID 及其保證手段
  • 2 事務的隔離級別
  • 3 多版本并發控制 MVCC
  • 4 MVCC 實現流程
  • 5 RR 等級下使用 MVCC 防止幻讀
• 四 規范與優化建議
• • 1 索引、數據表設計
  • 2 索引失效的情況（優化查詢需要避免）
  • 3 連接查詢優化
  • 4 分庫和分表
• 五 InnoDB 的鎖機制
• • 1 表鎖：S、X、IS、IX
  • 2 行鎖：S、X
  • 3 行鎖的進一步劃分
• 六 SQL 查詢
• • 1 語法
  • 2 執行順序
  • 3 常用函數 / 關鍵字

---

一 存儲引擎

1 MyISAM 與 InnoDB 的差異

• MySQL 5.5 之前，MyISAM 引擎是 MySQL 的默認存儲引擎，之后的默認引擎是 InnoDB
• 相比之下，InnoDB 具有 支持事務、支持行級鎖、支持外鍵、支持數據庫異常崩潰后的安全恢復（redo log） 的特性

2 表級鎖與行級鎖

• 表級鎖： MySQL 中鎖定 粒度最大 的一種鎖，對當前操作的整張表加鎖，實現簡單，資源消耗也比較少，加鎖快，不會出現死鎖。其鎖定粒度最大，觸發鎖沖突的概率最高，并發度最低，MyISAM 和 InnoDB 引擎都支持表級鎖
• 行級鎖： MySQL 中鎖定 粒度最小 的一種鎖，只針對當前操作的行進行加鎖。 行級鎖能大大減少數據庫操作的沖突。其加鎖粒度最小，并發度高，但加鎖的開銷也最大，加鎖慢，會出現死鎖

---

二 索引

使用索引不一定能提升查詢性能，在表比較小時，全表掃描的速度可能比使用索引更快

1 主鍵索引與二級索引

• 主鍵索引存放的數據是表中的一條數據，二級索引存放的數據是主鍵索引
• 一張數據表有只能有一個主鍵，并且主鍵不能為 null，不能重復
• 一般而言，不發生索引覆蓋時，在根據主索引搜索時，直接找到 key 所在的節點即可取出數據；在根據輔助索引查找時，則需要先取出主鍵的值，再使用主索引進行數據查找
• 除非發生索引覆蓋（需要查詢的字段正好是索引的字段，無論主索引或二級索引）的情況，否則使用二級索引會導致回表（當查到索引對應的主鍵后，還需要根據主鍵再到數據文件或表中查詢）
• 如果沒有主鍵也沒有合適的唯一索引，那么 InnoDB 內部會生成一個隱藏的主鍵作為聚集索引，這個隱藏的主鍵是一個6個字節，類型為長整型的列，該列的值會隨著數據的插入自增
• 二級索引的內節點，也保存了主鍵的值，避免相同的二級索引值造成歧義
• 聯合索引本質上也是二級索引，多個屬性建立聯合索引只會建立一棵B+樹

2 聚簇索引與非聚簇索引

• 聚簇索引指的是，索引和數據存放在一起。對于 InnoDB 引擎表來說，該表的索引(B+樹)的每個非葉子節點存儲索引，葉子節點存儲索引和索引對應的數據
• 主鍵索引是聚簇索引，二級索引是非聚簇索引

索引類型優點缺點

聚簇索引	查詢速度快，無需回表	需要依賴有序的數據（因為數據結構是B+樹，需要在插入時排序）；更新代價大（如果對索引列的數據被修改時，那么對應的索引也將會被修改）
非聚簇索引	更新代價比聚簇索引小	需要依賴有序的數據；可能會回表

3 數據結構：哈希表

• 插入數據時，根據 key 進行哈希運算，得到 bucket 的位置，如果該位置無 value 則插入成功，如果有則發生了哈希沖突，使用拉鏈法或者紅黑樹解決（類似 Java 的 HashMap）
• 只支持全值的精確查詢，時間復雜度僅為O(1)，但不支持順序或者范圍查詢

4 數據結構：B樹

• MongoDB 采用的索引類型，多路平衡查找樹
• B樹的中間節點存放的也是數據；葉節點之間沒有連接
• B樹的檢索的過程相當于對范圍內的每個節點的關鍵字做二分查找，可能還沒有到達葉子節點，檢索就結束了

5 數據結構：B+樹

• MyISAM 和 InnoDB 均采用的索引類型，多路平衡查找樹
• B+樹的中間節點只存放索引，數據全部都在葉節點上；葉節點之間有連接
• 相對于B樹而言，對范圍查找的支持更好
• 查詢效率更加穩定，因為每次查詢必定會訪問到葉節點
• 葉子節點構成一個有序鏈表，而且葉子節點本身按照關鍵字的大小從小到大順序鏈接
• B+樹的階數并非越大越好：階數很大時，一個節點的大小會超過一個頁的大小，讀取這樣一個節點會導致多次I/O操作，造成性能下降。要盡量讓每個節點的大小等于一個頁的大小

6 數據結構：跳表

• 在 Redis 中的 Zset 使用到的數據結構
• 為什么在 MySQL 中選擇 B+ 樹而非跳表作為索引的數據結構？
  如果是查詢磁盤文件，B+ 樹會比跳表的性能好很多，因為磁盤查詢性能比內存差，所以要盡量減少查詢的次數
  B+ 樹每個節點按頁存放數據，每次查詢可以查詢一批數據到內存中；而且 B+ 樹的層數低，可以減少訪問磁盤的次數

7 為什么不使用紅黑樹**

• MySQL 用 I/O 次數衡量查詢效率，磁盤查找存取的次數往往由樹的高度所決定

紅黑樹是內排序使用的數據結構，B+ 樹常用于外排序

紅黑樹的高度通常更高（因為是二叉樹），需要的磁盤 I/O 次數更多，效率低；B+樹可以有多個子節點，樹的高度通常為1~3層，效率高

B+樹的一個節點對應一個頁，如果使用紅黑樹的話每個節點（頁）存放一條數據，造成很大的浪費

8 為什么不使用B樹**

B樹執行范圍查詢時只能按照類似于中序遍歷的方式進行，效率不如B+樹在葉節點的順序訪問

B樹/B+樹的特點就是每層節點數目非常多，層數很少，就是為了減少 I/O 次數，但是B樹的每個節點都存放數據，這無疑增大了節點大小，增加了磁盤 I/O 次數（磁盤I/O一次讀出的數據量大小是固定的，單個數據變大，每次讀出的就少，導致 I/O次數增多），而B+樹除了葉子節點均不存儲數據，節點小，磁盤 I/O 次數就少

---

三 MySQL 事務

1 ACID 及其保證手段

• 原子性：事務是最小的執行單位，不允許分割（事務內的一系列操作，要么全都做，要么全不做）
• 一致性：事務執行前后，數據庫的一致性保持不變
• 隔離性：并發進行的事務之間互不影響
• 持久性：事務提交后，對數據庫中數據的修改是永久的

MySQL InnoDB 引擎使用 redo log 保證事務的持久性，使用 undo log 來保證事務的原子性；
鎖機制、MVCC 等手段來保證事務的隔離性（ 默認隔離級別是可重復讀）；
保證了事務的持久性、原子性、隔離性之后，一致性才能得到保障

2 事務的隔離級別

隔離級別&出現的異常臟讀（讀到未提交數據）不可重復讀（兩次讀取同一數據結果不同）幻讀（兩次查詢結果數目不同）

讀未提交	√	√	√
讀提交	×	√	√
可重復讀	×	×	√
串行化	×	×	×

• 可重復讀 使用 MVCC + Next-key Lock 也可以避免幻讀

3 多版本并發控制 MVCC

• 簡言之，MVCC 處理的是 讀數據 的問題，寫數據必須依靠加鎖
• 普通的 SELECT 語句在 讀提交 和 可重復讀 隔離級別下會使用到 MVCC，主要針對的也是這兩種隔離級別（因為這兩種隔離級別要求讀到的是 已經提交了的 事務修改過的記錄），另外兩種隔離級別不適用 MVCC
• MVCC 的讀指的是 快照讀（讀取的是快照數據） , 而非 當前讀（當前讀讀取的是記錄的最新版本，讀取時還要保證其他并發事務不能修改當前記錄，會對讀取的記錄進行加鎖）
• 當前讀實際上是一種加鎖的操作，是悲觀鎖的實現，而MVCC本質是采用樂觀鎖思想的一種方式

4 MVCC 實現流程

• 其實現主要依賴于 記錄的隱藏字段 + UndoLog + ReadView
• 讀提交 和 可重復讀 關于 ReadView 的區別是，在每一次進行普通 SELECT 操作前都會生成一個ReadView ；可重復讀只在第一次進行普通 SELECT 操作前生成一個 ReadView，之后的查詢操作都重復使用相同的 ReadView
• ReadView 包含主要結構

creator_trx_id創建這個 ReadView 的事務 ID（只讀事務為0，修改記錄的事務會被分配 ID）

trx_ids	生成 ReadView 時，活躍的讀寫事務的事務 ID 列表
up_limit_id	活躍的事務中最小的事務 ID
low_limit_id	生成 ReadView 時，系統中應該分配給下一個事務的 ID 值

注意：low_limit_id 并不是 trx_ids 中的最大值，事務id是遞增分配的。比如，現在有id為1，2，3這三個事務，之后id為3的事務提交了。那么一個新的讀事務在生成 ReadView 時，trx_ids就包括1和2，up_limit_id的值就是1，low_limit_id的值就是4

• ReadView 規則：

• 如果被訪問版本的 trx_id 屬性值與 ReadView 中的 creator_trx_id 值相同，說明該記錄的修改是由當前事務創建的，允許訪問
• 如果被訪問版本的 trx_id 屬性值小于 ReadView 中的 up_limit_id 值，表明生成該版本的事務在當前事務生成 ReadView 之前已經提交，允許訪問
• 如果被訪問版本的 trx_id 屬性值大于或等于 ReadView 中的 low_limit_id 值，表明生成該版本的事務在當前事務生成 ReadView 后才開啟，不允許訪問
• 如果被訪問版本的 trx_id 屬性值在 ReadView 的 up_limit_id 和 low_limit_id 之間，那就需要判斷一下 trx_id 屬性值是不是在 trx_ids 列表中：如果在，說明生成該版本的事務，在當前事務開啟時尚未提交，不允許訪問；反之說明生成該版本的事務，在當前事務開啟時已經提交，允許訪問

• MVCC 整體流程：

• 首先獲取事務自己的版本號，也就是事務 ID；
• 獲取 ReadView；
• 查詢得到的數據，然后與 ReadView 中的事務版本號進行比較；
• 如果不符合 ReadView 規則，就需要從 Undo Log 中獲取歷史快照；
• 最后返回符合規則的數據，如果無符合規則的數據則返回空
  

5 RR 等級下使用 MVCC 防止幻讀

• 執行普通 SELECT 即快照讀時，可重復讀只會在事務開啟后的第一次查詢生成 Read View ，并使用至事務提交。所以在生成 ReadView 之后其它事務所做的更新、插入記錄版本對當前事務并不可見，實現了可重復讀和防止快照讀下的 幻讀
• 執行當前讀時，InnoDB 使用 Next-key Lock 來防止這種情況。當執行當前讀時，會鎖定讀取到的記錄的同時，鎖定它們的間隙，防止其它事務在查詢范圍內插入數據

---

四 規范與優化建議

1 索引、數據表設計

讓主鍵具有 AUTO_INCREMENT ，讓存儲引擎自己生成主鍵，而不是手動插入，讓插入的記錄的主鍵值依次遞增，避免頁面分裂帶來的性能損耗

字段的數據類型定義準確

設計數據表時遵循范式規則 1/2/3NF
1NF：數據表的每個字段不可拆分
2NF：數據表中非主屬性完全依賴于主屬性
3NF：數據表中的非主屬性不傳遞依賴于主屬性

對數據表進行適當的行、列拆分（分表）

數據庫和表的字符集統一使用 utf8mb4

表屬性盡量設置為 NOT NULL，因為 IS NOT NULL 不能使用索引

將聯合索引中，把過濾性最好（區分度最大）的屬性放在前面；把需要范圍查詢的屬性放在后面

2 索引失效的情況（優化查詢需要避免）

違背最佳左前綴法則
對于列 (age, class, name) 建立了聯合索引，如果查詢條件是 class=5 and name='zy' 等違背左前綴，則無法使用該索引
優化器可以決定 where 后面條件的順序，所以 class=5 and name='zy' and age=10 可以使用索引

計算、函數、類型轉換導致索引失效
WHERE name=123 不能使用索引；WHERE name='123' 可以使用索引

IS NULL 可以使用索引，IS NOT NULL 不能使用索引

范圍條件右邊（指的是定義聯合索引的右，而非 where 條件中的右）的列索引失效
對于列 (age, class, name) 建立了聯合索引，WHERE student.age=30 AND student.name = 'abc' AND student.classId>20 會導致 name 索引失效

不等于 != 導致索引失效

OR 前后存在非索引的列，索引失效：因為對于非索引的條件需要全表掃描，該情況下直接放棄使用索引而執行全表掃描

對于模糊查詢，通配符（%）在搜尋詞首出現，一般會導致不使用索引，"%ABC"不能使用，但"A%BC"可以使用

3 連接查詢優化

• 驅動表：無法避免全表掃描的表稱為驅動表
• 在決定哪個表做驅動表的時候，兩個表按照各自的條件過濾，過濾后計算參與 join 的各個字段的總數據量，數據量小的那個表，就是“小表”，應該作為驅動表
• 為了提高連接查詢效率，需要將小表作為驅動表，大表作為被驅動表，減少外層循環的次數
• LEFT JOIN 保證左表的每個記錄都會出現，即左表為驅動表，所以右表是關鍵，一定需要建立索引（右外連接反之）
• INNER JOIN 會自動決定驅動表、被驅動表
  對于連接屬性，如果兩表只有一個具有索引，則它作為被驅動表
  如果兩個表都在該屬性有索引，小表作為驅動表，大表作為被驅動表
• 需要JOIN 的字段，數據類型保持絕對一致，避免類型轉換導致索引失效

4 分庫和分表

切分定義應用場景

分庫	數據庫中的數據分散到不同的數據庫上	應用的并發量太大；數據庫中的數據占用的空間越來越大，備份時間越來越長
分表	對單表的數據進行拆分，可以是垂直拆分，也可以是水平拆分	單表的數據達到千萬級別以上，數據庫讀寫速度比較緩慢

分庫帶來的問題：

• join 操作 ： 同一個數據庫中的表分布在了不同的數據庫中，導致無法使用 join 操作，需要手動進行數據的封裝，比如在一個數據庫中查詢到一個數據之后，再根據這個數據去另外一個數據庫中找對應的數據
• 事務問題 ：同一個數據庫中的表分布在了不同的數據庫中，如果單個操作涉及到多個數據庫，那么數據庫自帶的事務就無法滿足要求
• 分布式 id ：分庫之后， 數據遍布在不同服務器上的數據庫，數據庫的自增主鍵已經沒辦法滿足生成的主鍵唯一了。需要為系統引入分布式 id

---

五 InnoDB 的鎖機制

該部分的參考

1 表鎖：S、X、IS、IX

• 意向鎖：
  當事務要在記錄上加上行鎖時，要首先在表上加上意向鎖，使得判斷表中是否有記錄正在加鎖更簡單
  意向鎖不與行級鎖發生沖突，因為它屬于表級鎖
  意向鎖之間不發生沖突
• 表級鎖的兼容矩陣：
  

2 行鎖：S、X

行鎖是加在索引上的，如果查詢語句不使用索引的話，那么它就會升級到表鎖，最終造成效率低下

• 共享鎖（S）：加了鎖的記錄，所有事務都能去讀取但不能修改，同時阻止其他事務獲得相同數據集的排他鎖
• 排他鎖（X）：允許已經獲得排他鎖的事務去更新數據，阻止其他事務取得相同數據集的共享讀鎖和排他寫鎖

3 行鎖的進一步劃分

根據行鎖的位置不同進行劃分

Next-Key Lock

• 本質上是 Gap Lock + Record Lock，左開右閉
• MySQL 默認隔離級別是RR，在這種級別下，如果使用 select in share mode 或者 select for update 語句（即當前讀），那么 InnoDB 會使用 Next-Key Lock，防止幻讀，在上面已經討論過

Gap Lock

• 使用范圍條件而不是相等條件去檢索，并請求鎖時，InnoDB就會給符合條件的記錄的索引項加上鎖；而對于鍵值在條件范圍內但并不存在的記錄，就叫做間隙，InnoDB此時也會對間隙加鎖
• 在 RU 和 RC 兩種隔離級別下，即使你使用 select in share mode 或 select for update，也無法防止幻讀。因為這兩種隔離級別下只會有行鎖，而不會有間隙鎖；而如果是 RR 隔離級別的話，就會在間隙上加上間隙鎖

Record Lock

• 最簡單的行鎖

Insert Intention Lock

• 插入意圖鎖是一種間隙鎖，在行執行 INSERT 之前的插入操作設置。如果多個事務 INSERT 到同一個索引間隙之間，但沒有在同一位置上插入，則不會產生任何的沖突
• 假設有值為4和7的索引記錄，現在有兩事務分別嘗試插入值為 5 和 6 的記錄，在獲得插入行的排他鎖之前，都使用插入意向鎖鎖住 4 和 7 之間的間隙，但兩者之間并不會相互阻塞，因為這兩行并不沖突

---

六 SQL 查詢

1 語法

• select 的屬性（不包括函數使用的）必須在 group by 后面出現

select [distinct] from join on where group by having union order by limit

2 執行順序

1. from # 首先進入from字句 2. on # 根據條件選擇需要連接的行 3. join # 執行連接 4. where # 對連接結果過濾 5. group by # 分組（在分組之前執行了 select 后面的 if、substring_index... 等非運算操作） 6. avg(), sum(), count()... behind select # 執行函數 7. having # 對各個分組分別進行過濾 8. select # 選擇結果 9. distinct # 結果去重 10. union # 將當前結果并上其它結果 11. order by [asc, desc] # 排序 12. limit # 選擇指定行作為結果

3 常用函數 / 關鍵字

day(date) / month(date) / year(date)：獲取日/月/年

# 獲取2021年8月里，每天的練習量 select day(date) day, count(*) question_cnt from question_practice_detail where year(date) = 2021 and month(date) = 8 group by day

if(cond, true_val, false_val)：條件正確時選擇前者，否則后者

# 分別查看 25歲以下和25歲及以上 兩個年齡段的用戶數量 # 這里先執行了 if 再執行了 group by select if(age>=25, '25歲及以上', '25歲以下') as age_cut, count(device_id) as number from user_profile group by age_cut # 復旦大學的每個用戶在8月份練習的總題目數和回答正確的題目數情況 # 主要問題是統計 result = 'right' 的行數，count(result = 'right') 是錯誤的寫法，應該 sum(if(result = 'right', 1, 0)) select t1.device_id, t1.university, count(t2.question_id) question_cnt, sum(if(t2.result = 'right', 1, 0)) right_question_cnt from user_profile t1 left join (select device_id, result, question_idfrom question_practice_detailwhere month(date) = 8) t2 on t1.device_id = t2.device_id where university = '復旦大學' group by device_id

case...when...then...else...end

# 將用戶劃分為20歲以下，20-24歲，25歲及以上三個年齡段 selectdevice_id,gender,casewhen age >= 25 then '25歲及以上'when age >= 20 then '20-24歲'when age < 20 then '20歲以下'else '其他'end age_cut from user_profile

union [all]：不加 all 會自動去重

substring(field, separator, index)：如果 index > 0 則取前綴，否則取后綴

upper(str)：轉為大寫

concat(str1, str2)：拼接字符串

substring(str, start, end)：子串，索引從1開始

總結

以上是生活随笔為你收集整理的后端学习 - MySQL存储引擎、索引与事务的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。