 # 1. 邏輯架構 ## 1.1. 大多數基於網路的客戶端/伺服器工具或伺服器都有類似的服務 ### 1.1.1. ...
1. 邏輯架構
1.1. 大多數基於網路的客戶端/伺服器工具或伺服器都有類似的服務
1.1.1. 連接處理
1.1.2. 身份驗證
1.1.3. 確保全全性
1.2. 核心層
1.2.1. 查詢解析、分析、優化、以及所有的內置函數
1.2.2. 跨存儲引擎的功能
1.2.2.1. 存儲過程
1.2.2.2. 觸發器
1.2.2.3. 視圖
1.3. 存儲引擎層
1.3.1. 存儲引擎負責MySQL中數據的存儲和提取
1.3.2. 和GNU/Linux下的各種文件系統一樣，每種存儲引擎都有其優勢和劣勢
1.3.3. 優化器並不關心表使用的是什麼存儲引擎，但存儲引擎對於查詢優化是有影響的
2. 查詢緩存
2.1. query cache
2.2. 隨著併發性的增加，查詢緩存成為一個讓人詬病的瓶頸
2.3. MySQL 5.7.20版本開始，查詢緩存已經被官方標註為被棄用的特性
2.4. 在8.0版本中被完全移除
2.5. 緩存被頻繁請求的結果集依然是一個很好的實踐
2.5.1. 一個流行的設計模式是在memcached或Redis中緩存數據
3. 併發控制
3.1. 只要有多個查詢需要同時修改數據，就會產生併發控制問題
3.2. 併發控制的級別
3.2.1. 伺服器級別
3.2.2. 存儲引擎級別
3.3. 讀寫鎖
3.3.1. 從電子錶格中讀取數據不會有什麼麻煩，即使很多人同時讀取也不會有問題
3.3.2. 讀鎖（read lock）
3.3.2.1. 共用鎖（shared lock）
3.3.2.2. 資源上的讀鎖是共用的，或者說是相互不阻塞的
3.3.3. 寫鎖（write lock）
3.3.3.1. 排他鎖（exclusive lock）
3.3.3.2. 寫鎖則是排他的，也就是說，一個寫鎖既會阻塞讀鎖也會阻塞其他的寫鎖
3.3.3.3. 只有這樣才能確保在特定的時間點只有一個客戶端能執行寫入，並防止其他客戶端讀取正在寫入的資源
3.3.3.3.1. 這是出於安全策略的考慮
3.3.4. 處理併發讀/寫訪問的系統通常實現一個由兩種鎖類型組成的鎖系統
3.3.5. 在實際的資料庫系統中，每時每刻都在發生鎖定
3.3.6. 如果資料庫伺服器以可接受的方式執行，鎖的管理速度足夠快，那麼不會引起客戶端的感知
3.3.7. 鎖是資料庫實現一致性保證的方法
3.4. 鎖的粒度
3.4.1. 一種提高共用資源併發性的方式就是讓鎖定對象更有選擇性
3.4.2. 儘量只鎖定包含需要修改的部分數據，而不是所有的資源
3.4.3. 只對需要修改的數據片段進行精確的鎖定
3.4.4. 讓鎖定的數據量最小化，理論上就能保證在給定資源上同時進行更改操作，只要被修改的數據彼此不衝突即可
3.4.5. 如果系統花費大量的時間來管理鎖，而不是存取數據，那麼系統的性能可能會受影響
3.5. 鎖策略
3.5.1. 鎖定策略是鎖開銷和數據安全性之間的平衡，這種平衡會影響性能
3.5.2. 表鎖（table lock）
3.5.2.1. MySQL中最基本也是開銷最小的鎖策略
3.5.2.2. 它會鎖定整張表
3.5.2.2.1. 只有沒有人執行寫操作時，其他讀取的客戶端才能獲得讀鎖，讀鎖之間不會相互阻塞
3.5.2.3. 寫鎖隊列和讀鎖隊列是分開的，但寫鎖隊列的優先順序絕對高於讀隊列
3.5.3. 行級鎖（row lock）
3.5.3.1. 行級鎖是在存儲引擎而不是伺服器中實現的
3.5.3.2. 可以最大程度地支持併發處理（也帶來了最大的鎖開銷）
3.5.3.3. 允許多人同時編輯不同的行，而不會阻塞彼此
3.5.3.4. 一般都是在表中施加行級鎖（row level lock），為了在鎖比較多的情況下儘可能地提供更好的性能，鎖的實現方式非常複雜
3.5.3.5. 伺服器可以執行更多的併發寫操作
3.5.3.6. 代價是需要承擔更多開銷
3.5.3.6.1. 跟蹤誰擁有這些行級鎖
3.5.3.6.2. 已經鎖定了多長時間
3.5.3.6.3. 行級鎖的類型
3.5.3.6.4. 何時該清理不再需要的行級鎖
4. 事務
4.1. 事務就是一組SQL語句，作為一個工作單元以原子方式進行處理
4.2. 作為事務的一組語句，要麼全部執行成功，要麼全部執行失敗
4.3. 存在高度複雜且緩慢的兩階段提交系統的典型原因
4.3.1. 為了應對各種失敗場景
4.3.1.1. 連接可能會斷開
4.3.1.2. 會超時
4.3.1.3. 資料庫伺服器在操作執行過程中會崩潰
4.4. ACID
4.4.1. 原子性（atomicity）
4.4.1.1. 一個事務必須被視為一個不可分割的工作單元，整個事務中的所有操作要麼全部提交成功，要麼全部失敗回滾
4.4.2. 一致性（consistency）
4.4.2.1. 資料庫總是從一個一致性狀態轉換到下一個一致性狀態
4.4.3. 隔離性（isolation）
4.4.3.1. 一個事務所做的修改在最終提交以前，對其他事務是不可見的，這就是隔離性帶來的結果
4.4.4. 持久性（durability）
4.4.4.1. 一旦提交，事務所做的修改就會被永久保存到資料庫中
4.4.4.2. 不可能有100%的持久性保障
4.4.4.3. 如果資料庫本身就能做到真正的持久性，那麼備份又怎麼能增加持久性?
4.4.5. ACID事務和InnoDB引擎提供的保證是MySQL中最強大、最成熟的特性之一
4.4.6. 除非系統通過嚴格的ACID測試，否則空談事務的概念是不夠的
4.5. 隔離級別
4.5.1. READ UNCOMMITTED（未提交讀）
4.5.1.1. 在事務中可以查看其他事務中還沒有提交的修改
4.5.1.2. 從性能上來說，READ UNCOMMITTED不會比其他級別好太多，卻缺乏其他級別的很多好處
4.5.1.3. 在實際應用中一般很少使用
4.5.1.4. 讀取未提交的數據，也稱為臟讀（dirty read）
4.5.2. READ COMMITTED（提交讀）
4.5.2.1. 大多數資料庫系統的預設隔離級別是READ COMMITTED
4.5.2.1.1. MySQL不是
4.5.2.2. 一個事務可以看到其他事務在它開始之後提交的修改
4.5.2.3. 在該事務提交之前，其所做的任何修改對其他事務都是不可見的
4.5.2.4. 允許不可重覆讀（nonrepeatable read）
4.5.2.4.1. 這意味著同一事務中兩次執行相同語句，可能會看到不同的數據結果
4.5.3. REPEATABLE READ（可重覆讀）
4.5.3.1. MySQL預設的事務隔離級別
4.5.3.2. 保證了在同一個事務中多次讀取相同行數據的結果是一樣的
4.5.3.3. 無法解決另外一個幻讀（phantom read）
4.5.3.4. 幻讀指的是當某個事務在讀取某個範圍內的記錄時，另外一個事務又在該範圍內插入了新的記錄，當之前的事務再次讀取該範圍的記錄時，會產生幻行（phantom row)
4.5.3.5. InnoDB和XtraDB存儲引擎通過多版本併發控制（MVCC，Multiversion Concurrency Control）解決了幻讀的問題
4.5.4. SERIALIZABLE（可串列化）
4.5.4.1. 最高的隔離級別
4.5.4.2. 通過強制事務按序執行，使不同事務之間不可能產生衝突，從而解決了幻讀問題
4.5.4.3. 實際應用中很少用到這個隔離級別，除非需要嚴格確保數據安全且可以接受併發性能下降的結果
4.5.5. 隔離級別之間的利與弊
