這本書去年11月出的,今年中文版也出了,并且直接上了微信讀書,之后有空就讀一讀,分享下讀書筆記~
原文內容比較充實,建議有時間可以讀一下原文.
第一章主要是個概覽.
MySQL的邏輯架構
默認情況下,每個客戶端連接都會在服務器行程中擁有一個執行緒,該連接的查詢只會在這個單獨的執行緒中執行,該執行緒駐留在一個內核或者CPU上.
執行緒池
優化器會向存盤引擎詢問它的一些功能、某個具體操作的成本,以及表資料的統計資訊.
query cache 5.7.20棄用 8.0移除
考慮應用自己在redis中快取
并發控制
只要有多個查詢需要同時修改資料,就會產生并發控制問題
讀寫鎖
處理并發讀/寫訪問的系統通常實作一個由兩種鎖型別組成的鎖系統
這兩種鎖通常被稱為共享鎖(shared lock)和排他鎖(exclusive lock),也叫讀鎖(read lock)和寫鎖(write lock)
鎖的粒度
通過降低鎖的粒度提高共享資源并發性
只鎖定包含需要修改的部分資料
表鎖
table lock
最基本 開銷最小的鎖策略(鎖本身的開銷 不是指查詢/修改性能)
行級鎖
row lock
最大程度支持并發處理 最大的鎖開銷
行級鎖是在存盤引擎中實作
事務
事務就是一組SQL陳述句,作為一個作業單元以原子方式進行處理
要么全部執行成功 要么全部執行失敗
ACID
隔離級別
這里談的是ANSI SQL中的定義
-
READ UNCOMMITTED: 未提交讀
在事務中可以查看其他事務中還沒有提交的修改
臟讀(dirty read): 讀取未提交的資料 -
READ COMMITTED: 已提交讀
大多數資料庫系統的默認級別
但MySQL不是
一個事務可以看到其他事務在它開始之后提交的修改,但在該事務提交之前,其所做的任何修改對其他事務都是不可見的.
允許不可重復讀(nonrepeatable read) 同一個事務中兩次執行相同陳述句 可能看到不同結果 -
REPEATABLE READ: 可重復讀
解決了不可重復讀
無法解決幻讀(phantom read) 讀取范圍資料時 如果另一個事務在該范圍插入了新的 再次讀取會產生換行(phantom row)
InnoDB和XtraDB通過MVCC解決
這也是MySQL默認的隔離級別 -
SERIALIZABLE: 可串行化
該級別通過強制事務按序執行,使不同事務之間不可能產生沖突,從而解決了前面說的幻讀問題.
會在讀取的每一行資料上都加鎖,所以可能導致大量的超時和鎖爭用的問題.
使用場景較少 除非需要嚴格確保資料安全 并且接收并發性能下降
死鎖
兩個或多個事務相互持有和請求相同資源上的鎖,產生了回圈依賴.
當多個事務試圖以不同的順序鎖定資源時會導致死鎖.
資料庫系統實作了各種是說檢測和鎖超時機制
InnoDB目前處理死鎖的方式是將持有最少行級排他鎖的事務回滾
鎖的行為和順序和存盤引擎相關
console1:
start transaction ;
update user set user_name='cc11' where user_id=1;
update user set user_name='cc22' where user_id=2;
commit ;
console2:
start transaction ;
update user set user_name='cc222' where user_id=2;
update user set user_name='cc111' where user_id=1;
commit ;
單步執行
[40001][1213] Deadlock found when trying to get lock; try restarting transaction
事務日志
事務日志有助于提高事務的效率.存盤引擎只需要更改記憶體中的資料副本,而不用每次修改磁盤中的表,這會非常快.
事務日志只追加 順序I/O
WAL write-ahead logging 預寫日志 修改資料最終要兩次磁盤寫入
MySQL中的事務
描述的是InnoDB引擎中的事務
理解AUTOCOMMIT
默認開啟 單個陳述句也是包裹在事務中 自動提交
可以通過set autocommit=0/1進行開關
用begin或者start transaction來開啟事務
用commit提交 rollback回滾
有一些命令,當在活動的事務中發出時,會導致MySQL在事務的所有陳述句執行完畢前提交當前事務
比如一些DDL命令 alter table等
可以通過SET TRANSACTION ISOLATION LEVEL改變隔離級別 下一個事務開始時生效
在事務中混合使用存盤引擎
MySQL的事務由下層存盤引擎實作
在同一個事務中,混合使用多種存盤引擎是不可靠的.
隱式鎖定和顯式鎖定
InnoDB使用兩階段鎖定協議(two-phase locking protocol).
事務執行期間,隨時都可以獲取鎖,但鎖只有在提交或回滾后才會釋放,并且所有的鎖會同時釋放.
前面描述的鎖定機制都是隱式的.InnoDB會根據隔離級別自動處理鎖.
顯式的(不屬于SQL規范)
SELECT … FOR SHARE
SELECT … FOR UPDATE
MySQL還支持LOCK TABLES和UNLOCK TABLES
這兩個命令在服務器級別實作
因為InnoDB支持行級鎖 沒必要使用
建議: 除了在禁用AUTOCOMMIT的事務中可以使用之外,其他任何時候都不要顯式地執行LOCK TABLES,不管使用的是什么存盤引擎.
多版本并發控制
MySQL的大多數事務型存盤引擎使用的都不是簡單的行級鎖機制.它們會將行級鎖和可以提高并發性能的多版本并發控制(MVCC)技術結合使用.
不同資料庫的實作細節不一樣
可以認為MVCC是行級鎖的一種變種 它在很多情況下避免加鎖 因此開銷更低
通過資料快照實作
- InnoDB為每個事務啟動時分配一個事務ID
- 該事務修改記錄時 向Undo log寫入一條如何恢復回去的undo記錄 事務回滾指標指向該記錄
- 當不同會話讀取聚簇主鍵索引記錄時 InnoDB會把記錄的事務ID和該會話的讀取視圖比較 如果更改他的事務未提交 則跟蹤undo log直到一個符合可見條件的事務ID
大多數讀取通過這種方式不需要獲取鎖(通過讀取快照) 缺點是存盤引擎會對每一行存盤更多資料 做更多作業
MVCC僅適用于REPEATABLE READ和READ COMMITTED隔離級別.
(可以想象對于可重復讀 讀取的事務id固定為事務進行中第一次讀的可見事務id 對于讀已提交 讀最新的可見事務id
另外兩個因為不需要事務版本(一個是臟讀 一個是串行化的) 和MVCC不是很適配(當然要看不同引擎的實作)
復制
Replication
一主多從
資料檔案結構
在8.0版本中,MySQL將表的元資料重新設計為一種資料字典,包含在表的.ibd檔案中
使得表結構上的資訊支持事務和原子級資料定義更改
除了以來information_schema檢索表定義和元資料
引入了字典物件快取 LRU的記憶體快取
使得服務器訪問表的元資料減少了I/O
每個表的.ibd和.frm檔案被替換為已經被序列化的字典資訊(.sdi).
InnoDB引擎
為處理大量短期事務而設計 這些事務預期通常是正常提交 很少會被回滾
默認情況下,InnoDB將資料存盤在一系列的資料檔案中,這些檔案統被稱為表空間(tablespace)
InnoDB使用MVCC來實作高并發性,并實作了所有4個SQL標準隔離級別.
默認為REPEATABLE READ隔離級別,并且通過間隙鎖(next-key locking)策略來防止在這個隔離級別上的幻讀：
InnoDB不只鎖定在查詢中涉及的行,還會對索引結構中的間隙進行鎖定,以防止幻行被插入
基于聚簇索引構建
但是,因為二級索引（secondary index,非主鍵索引）需要包含主鍵列,如果主鍵較大,則其他索引也會很大.如果表中的索引較多,主鍵應當盡量小.
微信讀書: https://weread.qq.com/web/bookDetail/00a32b70813ab746fg018ec7
博客位置: https://bingowith.me/2022/11/08/high-performance-mysql-4th-ch01-note/
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/530592.html
標籤：其他
上一篇：MySQL主從復制