???一、基礎(chǔ)架構(gòu)

1.連接器
1.會先連接到這個數(shù)據(jù)庫上，這時候接待你的就是連接器。連接器負(fù)責(zé)跟客戶端建立連接、獲取權(quán)限、維持和管理連接

2.用戶密碼連接成功之后，會從權(quán)限表中拿出你的權(quán)限，后續(xù)操作權(quán)限都依賴于此時拿出的權(quán)限,這就意味著當(dāng)鏈接完成之后即使有人修改了你的用戶權(quán)限，也不會影響你先有的鏈接

3.長連接是指連接成功后，如果客戶端持續(xù)有請求，則一直使用同一個連接。短連接則是指每次執(zhí)行完很少的幾次查詢就斷開連 全部使用長鏈接的時候，你會發(fā)現(xiàn)內(nèi)存漲的非?？?#xff0c;因為mysql執(zhí)行過程中的臨時內(nèi)存都是管理在鏈接對象里面的，這些資源在鏈接斷開的時候才會釋放，可能占用內(nèi)存太大。

3，解決方案有兩個 1.判斷占用大內(nèi)存的查詢的時候斷開鏈接，之后要查詢再重新鏈接 2.果你用的是 MySQL 5.7 或更新版本，可以在每次執(zhí)行一個比較大的操作后，通過執(zhí)行 mysql_reset_connection 來重新初始化連接資

2.查詢緩存
會以key，value形式緩存執(zhí)行過的語句和執(zhí)行結(jié)果，一旦有更新或者刪除操作就會釋放 可以設(shè)置query_cache_type 判斷是否使用緩存。 8.0之后 不再使用緩存了

1、查詢語句不一致。前后兩條查詢SQL必須完全一致。

2、查詢語句中含有一些不確定的值時，則不會緩存。比如 now()、current_date()、curdate()、curtime()、rand()、uuid()等。

3、不使用任何表查詢。如 select ‘A’;

4、查詢 mysql、information_schema 或 performance_schema 數(shù)據(jù)庫中的表時，不會走查詢緩存。

5、在存儲的函數(shù)，觸發(fā)器或事件的主體內(nèi)執(zhí)行的查詢。

6、如果表更改，則使用該表的所有高速緩存查詢都變?yōu)闊o效并從緩存中刪除，這包括使用 MERGE 映射到已更改表的表的查詢。一個表可以被許多類型的語句改變，如 insert、update、delete、truncate rable、alter table、drop table、drop database。

2.分析器
分析語法，判斷語法是否正確

3 優(yōu)化器
決定使用哪個索引；或者在一個語句有多表關(guān)聯(lián)（join）的時候，決定各個表的連接順序

4 執(zhí)行器
二、redo log 和 bin log
1.undo log 與 MVCC
undo log是 Innodb 引擎專屬的日志，是記錄每行數(shù)據(jù)事務(wù)執(zhí)行前的數(shù)據(jù)。主要作用是用于實現(xiàn)MVCC版本控制，保證事務(wù)隔離級別的讀已提交和讀未提交級別。而 MVCC 相關(guān)的可以參考 https://www.cnblogs.com/mengxinJ/p/14053269.html#_label1_0_0

2、redo log 與 Buffer Pool
redo log存儲的內(nèi)容是對數(shù)據(jù)頁的修改邏輯。

如果每一次的更新操作都需要寫進磁盤，然后磁盤也要找到對應(yīng)的那條記錄，然后再更新，整個過程 IO 成本、查找成本都很高。為了解決這個問題，MySQL 的設(shè)計者就用了類似酒店掌柜粉板的思路來提升更新效率。而粉板和賬本配合的整個過程，其實就是 MySQL 里經(jīng)常說到的 WAL 技術(shù)，WAL 的全稱是 Write-Ahead Logging，它的關(guān)鍵點就是先寫日志，再寫磁盤，也就是先寫粉板，等不忙的時候再寫賬本

write pos 表示當(dāng)前正在記錄的位置，會向后記錄， checkpoint 表示數(shù)據(jù)落盤的邊界，也就是 checkpoint 與 write pos中間是已記錄的，當(dāng) write pos寫完 id_logfile_3后，會回到id_logfile_0循環(huán)寫，而追上 checkpomnit 后則需要先等數(shù)據(jù)進行落盤，等待 checkponit向后面移動一段距離再寫。

?

1.bin log
redo log 因為大小固定，所以不能存儲過多的數(shù)據(jù)，它只能用于未更新的數(shù)據(jù)落盤，而數(shù)據(jù)操作的備份恢復(fù)、以及主從復(fù)制是靠 bin log（如果數(shù)據(jù)庫誤刪需要還原，那么需要某個時間點的數(shù)據(jù)備份以及bin log）。5.7默認(rèn)記錄的是操作語句涉及的每一行修改前后的行記錄。

在更新到數(shù)據(jù)頁緩存或者 Change Buffer 后，首先進行 redo log 的編寫，編寫完成后將 redo log 設(shè)為 prepare 狀態(tài)，隨后再進行 binlog 的編寫，等到 binlog 也編寫完成后再將 redo log 設(shè)置為 commit 狀態(tài)。這是為了防止數(shù)據(jù)庫宕機導(dǎo)致 binlog 沒有將修改記錄寫入，后面數(shù)據(jù)恢復(fù)、主從復(fù)制時數(shù)據(jù)不一致。在斷電重啟后先檢查 redo log 記錄的事務(wù)操作是否為 commit 狀態(tài)：

1、如果是 commit 狀態(tài)說明沒有數(shù)據(jù)丟失，判斷下一個。

2、如果是 prepare 狀態(tài)，檢查 binlog 記錄的對應(yīng)事務(wù)操作（redo log 與 binlog 記錄的事務(wù)操作有一個共同字段 XID，redo log 就是通過這個字段找到 binlog 中對應(yīng)的事務(wù)的）是否完整（這點在前面 binlog 三種格式分析過，每種格式記錄的事務(wù)結(jié)尾都有特定的標(biāo)識），如果完整就將 redo log 設(shè)為 commit 狀態(tài)，然后結(jié)束；不完整就回滾 redo log 的事務(wù)，結(jié)束。

總結(jié)
提示：這里對文章進行總結(jié)：
例如：以上就是今天要講的內(nèi)容，本文僅僅簡單介紹了pandas的使用，而pandas提供了大量能使我們快速便捷地處理數(shù)據(jù)的函數(shù)和方法。