mysql 學習筆記--基礎篇

基礎篇

Day 1

01 | 基礎架構：一條SQL查詢語句是如何執行的？

• MySQL 能夠分爲 Server 層和存儲引擎層兩部分。

• 儘可能使用長鏈接，避免內存過大沒釋放的辦法

• 不要使用查詢緩存
• 總結，sever層：鏈接器，分析器，優化器，執行器

Day2

02 | 日誌系統：一條SQL更新語句是如何執行的？

• 與查詢流程不同的是，更新流程還涉及兩個重要的日誌模塊
• redo log（重作日誌）和 binlog（歸檔日誌）
• WAL 的全稱是 Write-Ahead Logging，它的關鍵點就是先寫日誌，再寫磁盤，也就是先寫粉板，等不忙的時候再寫帳本
• 當有一條記錄須要更新的時候，InnoDB 引擎就會先把記錄寫到 redo log（粉板）裏面，並更新內存，這個時候更新就算完成了。同時，InnoDB 引擎會在適當的時候，將這個操做記錄更新到磁盤裏面
• innoDB 的 redo log 是固定大小的，好比能夠配置爲一組 4 個文件，每一個文件的大小是 1GB，那麼這塊「粉板」總共就能夠記錄 4GB 的操做
• 
• 淺色框表示是在 InnoDB 內部執行的，深色框表示是在執行器中執行的

• 兩階段提交（上圖後3步）將 redo log 的寫入拆成了兩個步驟：prepare 和 commit
• 
• 

Day3

03 | 事務隔離：爲何你改了我還看不見？

• ACID（Atomicity、Consistency、Isolation、Durability，即原子性、一致性、隔離性、持久性）
• 如今用的是，mysql5.6 默認是 可重複讀（repeatable read）

• 對於一些從 Oracle 遷移到 MySQL 的應用，爲保證數據庫隔離級別的一致，你必定要記得將 MySQL 的隔離級別設置爲「讀提交」
• 

Day4

04 05 | 深刻淺出索引

• 索引模型：哈希表、有序數組和搜索樹
• 每個索引在 InnoDB 裏面對應一棵 B+ 樹。
• 普通索引查詢方式，則須要先搜索 k 索引樹，再到 ID 索引樹搜索一次。這個過程稱爲回表
• 基於非主鍵索引的查詢須要多掃描一棵索引樹。所以，咱們在應用中應該儘可能使用主鍵查詢
• 通常須要用自增量設置主鍵 NOT NULL PRIMARY KEY AUTO_INCREMENT
• KEY-VALUE類型能夠不用自增量，直接設置KEY爲主鍵
• 覆蓋索引：查詢選擇的列已經在普通索引樹上，就不須要回表
• 最左前綴：不僅是索引的所有定義，只要知足最左前綴，就能夠利用索引來加速檢索 例如 name like '朱%',name的索引也起做用
• 聯合索引：（a,b) 符合最左前綴，mysql5.6後能夠索引下推，減小回表次數。

Day5

06 | 全局鎖和表鎖 ：給表加個字段怎麼有這麼多阻礙？

• 全局鎖：官方自帶的邏輯備份工具是 mysqldump。當 mysqldump 使用參數–single-transaction 的時候，導數據以前就會啓動一個事務，來確保拿到一致性視圖。innoDB引擎支持，若是是MyISAM就須要用Flush tables with read lock (FTWRL)加全局鎖再備份。
• 表級鎖：表鎖的語法是 lock tables … read/write
• 表級鎖：元數據鎖 MDL（metadata lock)。MDL 不須要顯式使用，在訪問一個表的時候會被自動加上。MDL 的做用是，保證讀寫的正確性
• 
• alert 字段會有寫鎖，頻繁讀取的表若是添加字段會形成現成堵塞。
• 

07 | 行鎖功過：怎麼減小行鎖對性能的影響？

• 兩階段鎖協議:在 InnoDB 事務中，行鎖是在須要的時候才加上的，但並非不須要了就馬上釋放，而是要等到事務結束時才釋放。這個就是兩階段鎖協議。若是事務要鎖多行，建議要把訪問最多的那個鎖放在最後執行。
• 死鎖 死鎖檢測：
• 

Day6

08 | 事務究竟是隔離的仍是不隔離的？

• InnoDB 的行數據有多個版本，每一個數據版本有本身的 row trx_id，每一個事務或者語句有本身的一致性視圖。普通查詢語句是一致性讀，一致性讀會根據 row trx_id 和一致性視圖肯定數據版本的可見性。
• InnoDB 利用了「全部數據都有多個版本」的這個特性，實現了「秒級建立快照」的能力。