效能優化之資料庫篇
效能優化-資料庫篇1
首先我們要談論什麼是效能？
- 吞吐和延遲
- 沒有量化就沒有改進 ：監控和度量指標可以指導我們從哪裡入手
- 80/20原則：先優化效能瓶頸的地方
- 過早的優化是萬惡之源：選擇合適的優化時機
- 脫離場景談效能都是耍流氓：對效能的要求要符合實際
一般來說，DB/SQL操作的消耗在一次處理中佔比最大。DB/SQL優化是業務系統的效能核心
關係資料庫
什麼是關係資料庫？
1970年Codd提出關係模型，以關係代數理論為數學基礎。建立在關係資料庫模型基礎上的資料庫，稱為關係資料庫。
資料庫設計正規化
- 第一正規化（1NF）：所有屬性都不可再分
- 第二正規化（2NF）: 在滿足1NF的基礎上，消除非主屬性對碼的部分函式依賴
- 第三正規化（3NF）：在滿足2NF的基礎上，消除非主屬性對碼的傳遞函式依賴。消除表中列不依賴主鍵，而是依賴表中非主鍵列的情況。
名詞解釋：
函式依賴：一張表中，屬性X的值確定的情況下，必定能確定屬性Y的值，那麼就說Y函式依賴於X。寫作X->Y
完全函式依賴：
設X,Y是關係R的兩個屬性集合，X’是X的真子集，存在X→Y，但對每一個X’都有X’!→Y，則稱Y完全函式依賴於X
部分函式依賴：
設X,Y是關係R的兩個屬性集合，存在X→Y，若X’是X的真子集，存在X’→Y，則稱Y部分函式依賴於X。
傳遞函式依賴：Z函式依賴於Y，且Y函式依賴於X，那麼稱Z傳遞函式依賴於X。
碼
：設K為某表中的一個屬性或屬性組，除K外的所有屬性都完全函式依賴於K，那麼稱K為候選碼，簡稱碼。
非主屬性：除去主屬性的就是非主屬性
舉例說明：
下面表是否符合第二正規化？
（學號、課名）可以作為碼。
有 (學號，課名)->姓名，但是學號->姓名，存在非主屬性“姓名”對碼的部分函式依賴。
有 (學號，課名)->系名，但是學號->系名，存在非主屬性“系名”對碼的部分函式依賴。
所以不符合第二正規化。
下面表是否符合第三正規化？
主屬性是學號，有學號->系名，系名->系主任。所以系主任傳遞函式依賴於學號，所以不符合第三正規化。
常見資料庫
結構化查詢語言包含6個部分：
- 資料查詢語言（DQL），用於從表裡獲得資料
- 資料操作語言（DML），用於新增、修改、刪除
- 事務控制語句（TCL），用於事務提交、儲存點、回滾
- 資料控制語言（DCL）：它的語句通過GRANT或REVOKE實現許可權控制
- 資料定義語言（DDL）：其語句包括動詞CREATE、ALTER和DROP，建立表、修改表、刪除表、加索引等。
- 指標控制語言（CCL）：它的語句，像DECLARE CURSOR,FETCH INTO用於對一個或多個表單獨行的操作。
MySQL資料庫
MySQL資料庫的版本
- 4.0支援InnoDB,事務
- 2003年，5.0
- 5.6 歷史使用最多的版本
- 5.7 近期使用最多的版本
- 多主
- MGR高可用
- 分割槽表
- json
- 修復XA
- 8.0 較新和功能最完善的版本
- 通用表示式
- 持久化引數
- 自增列持久化
- 預設編碼utf8mb4
- DDL原子性
- JSON增加
- 不再對group by進行隱式排序
MySQL簡化的執行流程：
MySQL詳細執行流程
MySQL執行引擎：
| 儲存引擎 | myisam | innodb | memory | archive |
|---|---|---|---|---|
| 儲存限制 | 256TB | 64TB | 有 | 無 |
| 事務 | - | 支援 | - | - |
| 索引 | 支援 | 支援 | 支援 | - |
| 鎖的粒度 | 表鎖 | 行鎖 | 表鎖 | 行鎖 |
| 資料壓縮 | 支援 | - | - | 支援 |
| 外來鍵 | - | 支援 | - | - |
2.1 MySQL 索引原理
資料是按頁分塊的，當一個數據被用到時，其附近的資料也通常會馬上被使用
MySQL索引結構：
Mysql innodb的索引結構是B+樹。
B+樹簡單的說是一種平衡查詢樹，所有的記錄節點都是按大小順序存放在同一層的葉子節點上，由各葉子節點的指標開始連線。頁之間是雙向連結串列連線，頁裡面的資料是單向連結串列。
B+樹索引又分為聚集索引和輔助索引
聚集索引：
按照每張表的主鍵構造一顆B+樹，同時葉子節點存放的為整張表的行記錄資料，也叫聚集索引的葉子節點稱為資料頁。由於實際的資料頁只能按照一顆B+樹進行排序，因此每個表只能擁有一個聚集索引。
很多文件說：聚集索引按照順序物理的儲存資料，其實不是，它的儲存不是物理上連續的，而是邏輯上連續的。
非聚集索引
也叫輔助索引，葉子節點除了包含鍵值外，還包含找到與索引對應的行資料的指標。
如果需要在一顆高度為3的輔助索引中查詢資料，需要遍歷3次找到指定主鍵，如果聚集索引樹高度也為3，那麼還需要對聚集索引樹進行3次查詢，最終找到一個完整的行資料所在頁。
為什麼一般單表的資料不能超過2000萬？
答：首先一個頁16K。
- 按一行資料1k，那麼葉子節點一頁存16條資料。
- id佔8位元組，指標佔6位元組，一共14位元組。非葉子節點一頁存（16*1024/(8+6)）1170個這樣的單元。
可以算出2層的B+樹放1170x16=18724條資料。如果3層的B+樹1170x1170x16=21,902,400條資料。
所以如果超過這麼多資料，那麼B+樹就會變為4層，那麼查詢就慢了。
2.2 引數配置優化
連線請求的變數
- max_connections: 最大連線數，一般配置個5k-10k
- back_log
- wait_timeout和interative_timeout
緩衝區變數
4. key_buffer_size
5. query_cache_size（查詢快取簡稱 QC)
6. max_connect_errors：
7. sort_buffer_size
8. max_allowed_packet=32M
9. join_buffer_size=2M
10. thread_cache_size=300
配置 Innodb 的幾個變數
11. innodb_buffer_pool_size
12. innodb_flush_log_at_trx_commit
13. innodb_thread_concurrency=0
14. innodb_log_buffer_size
15. innodb_log_file_size=50M
16. innodb_log_files_in_group=3
17. read_buffer_size=1M
18. read_rnd_buffer_size=16M
19. bulk_insert_buffer_size=64M
20. binary log