連線/執行緒處理：
管理客戶端連線/會話[mysql threads]
解析器：
通過檢查sql查詢中的每個字元來檢查sql語法，並
為每個sql查詢
生成
sql_id
。此外，身份驗證檢查（使用者憑據）將在此階段發生。
優化程式：
根據儲存引擎建立有效的查詢執行計畫。
它將重寫乙個查詢。
示例：innodb具有共享緩衝區，因此優化器將從中獲取預快取的資料。
使用表統計資訊優化器將為sql查詢生成執行計畫。
授權檢查（使用者訪問許可權）將在此階段發生。
元資料快取：
快取物件元資料資訊和統計資訊。
查詢快取：
來自記憶體的共享相同查詢。如果在查詢快取中找到來自客戶端的相同查詢，則mysql伺服器從查詢快取中檢索結果，而不是再次解析和執行該查詢。
它是會話的共享快取，因此可以傳送乙個客戶端生成的結果集以響應另乙個客戶端發出的相同查詢。
查詢快取基於
sql_id
.select資料進入檢視是使用查詢快取預快取資料的最佳示例。
金鑰快取：
快取表索引。在 mysql 中金鑰是索引（在oracle金鑰是約束），如果索引大小小，那麼它將快取索引結構和資料葉。如果索引很大，那麼它將只快取索引結構。由myisam 使用儲存引擎。
儲存引擎：
管理物理資料（檔案管理）和位置的mysql元件。
儲存引擎負責執行sql語句並從資料檔案中獲取資料。
用作外掛程式，可以從執行mysql伺服器載入/解除安裝。其中一些引擎如下：
innodb：
- 多個資料檔案
- 使用innodb資料和日誌緩衝區的邏輯物件結構
ndb（適用於mysql群集）：
myisam：
- 表結構的frm
- 表索引的myi
- 表資料的myd
sql 語句查詢是首先會去快取中查詢是否有相同語句的記錄，沒有則會檢查 sql 的句法並且生成乙個 sql 查詢 id，然後是優化查詢的 sql 並執行語句，從儲存引擎中查詢資料。
innodb 的儲存分為表空間。表空間是與多個資料檔案（物件）相關聯的邏輯結構。每個表空間都包含頁面（塊），範圍和段
頁數（pages）： innodb的最小資料也稱為塊。預設頁面大小為16kb，頁面可以包含一行或多行，具體取決於行大小。
可用頁面大小：4kb，8kb，16kb，32kb，64kb
變數名稱：innodb_page_size
需要在初始化 mysqld 伺服器之前進行配置。
範圍（extends）： 它是一組頁面。為了獲得更好的 i / o 吞吐量，innodb 讀取或寫入一組頁面，即一次乙個範圍。
對於一組預設頁面大小為 16kb 的頁面，範圍大小最大為 1mb。
doublewrite 緩衝區一次讀取/寫入/分配或釋放資料到乙個範圍。
段（segments）： innodb表空間中的檔案集合。段中最多使用 4個範圍。
innodb 緩衝池：
innodb 儲存引擎的**緩衝區。在這個資料緩衝區中，我們載入塊和快取表和索引資料。
- innodb 快取表資料和索引的主存。
- 在專用資料庫伺服器上調整高達80％的物理記憶體。
- 跨所有會話的共享緩衝區。
- innodb 使用 lru（最近最少使用）頁面替換演算法。
- 正在重用的資料始終位於同一記憶體中。
- 不使用的資料最終將被淘汰。
更改緩衝區：
在記憶體更改緩衝區是 innodb 緩衝池的一部分，在磁碟上，它是系統表空間的一部分，因此即使在資料庫重啟後索引更改仍保持緩衝。更改緩衝區是一種特殊的資料結構，可以將更改快取到二級索引頁當受影響的頁面不在緩衝池中時。
redo 日誌緩衝區：
用於 redo 日誌的緩衝區，儲存資料以寫入 redo 日誌。定期將資料從 redo 日誌緩衝區重新整理到 redo 日誌。將資料從記憶體重新整理到由 innodb_log_at_trx_commit 和 innodb_log_at_timeout 配置選項管理的磁碟。
- 比較大的 redo 日誌緩衝區可以在事務提交之前執行大型事務，而無需將 redo 日誌寫入磁碟。
- 變數：
innodb_log_buffer_size（預設為16m）
系統表空間：
除了表資料儲存之外，innodb 的功能還需要查詢表元資料並儲存和檢索 mvcc 資訊以支援 acid 規範性和事務隔離。它包含 innodb 物件的幾種型別的資訊。
變數：innodb_data_file_path = / ibdata / ibdata1：10m：autoextend
通過啟用innodb_file_per_table（預設）選項，我們可以將每個新建立的表（資料和索引）儲存在單獨的表空間中。此儲存方法的優點是磁碟資料檔案中的碎片較少。
常規表空間：
用於儲存多個表資料的共享表空間。在 mysql 5.7.6 中介紹。使用者必須使用 create tablespace 語法建立它。tablespace 選項可以與 create table 一起使用來建立表，使用 alter table 來移動表到常規表中。
- 記憶體優於 innodb_file_per_table 儲存方法。
- 支援 antelope 和 barracuda 檔案格式。
- 支援所有行格式和相關功能。
- 可以建立外部資料目錄。
innodb 資料字典：
系統表空間中的儲存區域由內部系統表組成，包含物件[表，索引，列等]的元資料資訊
雙寫緩衝區：
系統表空間中的儲存區域，innodb在寫入資料檔案中的正確位置之前從innodb緩衝池寫入頁面。
如果mysqld程序崩潰在頁面中間寫入，則在崩潰恢復時，innodb 可以從 doublewrite 緩衝區中找到頁面的良好副本。
變數：inndb_doublewrite（預設啟用）
redo 日誌：
用於崩潰恢復。在 mysqld 啟動時，innodb 執行自動恢復以糾正那些不完整事務寫入的資料。在 mysqld 意外關閉之前，那些沒有完成資料更新的事務，將在下次mysqld 啟動時，自動重做那未完成更新資料檔案的事務，即使是在mysqld沒有連線的情況下。。它使用 lsn（日誌序列號）值。
大量資料更改無法快速寫入磁碟，因此它將 redo ，然後再轉到磁碟。
為什麼我們需要 redo 以進行恢復？
讓我們舉乙個例子，使用者在 innodb 緩衝區中更改資料並提交，在寫入磁碟之前需要先去的地方。因為在崩潰緩衝區的情況下資料會丟失，這就是我們需要 redo 日誌的原因。
- 在 redo 時，所有更改都將使用 row_id，舊列值，新列值，session_id 和時間等資訊。
- 乙個提交完整資料將在磁碟下的資料檔案中。
- 變數：
innodb_log_file_in_group = [ redo 檔案組的數量]
innodb_log_file_size = [每個 redo 檔案的大小]
undo 表空間和日誌：
undo 表空間包含乙個或多個undo日誌檔案。
undo 通過保留活動事務 [mvcc] 的已修改未提交資料來管理一致讀取。從該儲存區域檢索未修改的資料。還原日誌也稱為回滾段
預設情況下，undo 日誌是系統表空間的一部分，mysql 允許將 undo 日誌儲存在單獨的表空間中 [在 mysql 5.6 中引入]。在初始化 mysqld 伺服器之前需要配置。
- 當我們配置單獨的表空間時，系統表空間中的日誌變為非活動狀態。
- 需要在初始化 mysqld 伺服器之前進行配置，之後無法更改。
- 我們截斷 undo 日誌，但不能刪除。
- 變數：
innodb_undo_tablespace：撤銷表空間的數量，預設為 0
innodb_undo_directory：undo表空間的位置，預設為 data_dir，大小為 10mb。
innodb_undo_logs：undo日誌數量，預設值和最大值為「128」
臨時表空間：
用於儲存和檢索臨時表和相關物件的已修改未提交資料的儲存。介紹 mysql 5.7.2 並在伺服器執行時用於回滾臨時表更改。
- 臨時表的 undo 日誌駐留在臨時表空間中。
- 在伺服器啟動時重新建立預設表空間檔案 ibtmp1。
- 不習慣崩潰恢復。
- 優勢：通過避免臨時表和相關物件的 redo 日誌的 io 來提高效能。
- 變數：
innodb_temp_data_file_path = ibtmp1：12m：autoextend（預設）
Activiti架構與元件 （二）
modeling activiti modeler,activiti designer,activiti kickstart.runtime activiti engine management activiti explorer,activiti rest activiti engine 最核心模...
Impala核心元件與架構
核心元件 statestore daemon 負責收集分布在集群中各個impalad程序的資源資訊 各節點健康狀況，同步 節點資訊.負責query的排程 catalog daemon 分發表的元資料資訊到各個impalad中 接收來自statestore的所有請求 impala daemon 最核心...
Serverless 的執行原理與元件架構
本文重點 下開發者使用 serverless 時經常遇到的一些問題，以及如何解決 過去一年，我們和大量 serverless 使用者進行了線上和線下的交流，了解大家的業務場景 對 serverless 的看法和使用體驗。大部分使用者認為 serverless 會是雲計算下一階段的必然趨勢，但不是現在...