1. 線程

1.1. MySQL服務端是多線程軟體。它的每個組件都使用線程

1.2. 每個線程至少有兩個唯一標識符

1.2.1. 操作系統線程ID

1.2.2. MySQL內部線程ID

2. 對象類型

2.1. OBJECT_TYPE列

2.2. EVENT

2.3. FUNCTION

2.4. PROCEDURE

2.5. TABLE

2.6. TRIGGER

3. Performance Schema

3.1. 一個經常受到批評的特性

3.1.1. 早期版本的MySQL對其的實現不夠理想，導致資源消耗較高

3.2. 提供了有關MySQL伺服器內部運行的操作上的底層指標

3.3. 應該啟用Performance Schema，按需動態地啟用插樁和消費者表，通過它們提供的數據可以解決可能存在的任何問題——查詢性能、鎖定、磁碟I/O、錯誤等

3.4. 充分利用sys schema是解決常見問題的捷徑。這樣做將為你提供一種可以直接從MySQL中測量性能的方法

3.5. 程式插樁（instrument）

3.6. 消費者表（consumer）

3.7. 測量結果存儲在Performance Schema資料庫的多個表中

3.7.1. MySQL 8.0.25社區版的performance_schema中包含110個表

3.8. 摘要是一種通過刪除查詢中的變數來聚合查詢的方法

3.9. 實例表（Instance）

3.9.1. 實例是指對象實例，用於MySQL安裝程式

3.10. 設置表（Setup）

3.10.1. 用於performance_schema的運行時設置

3.11. metadata_locks表保存關於元數據鎖的數據

3.12. Performance Schema收集的數據保存在記憶體中

3.13. 標準MySQL發行版包括一個和performance_schema數據配套使用的sys schema，它全部基於performance_schema上的視圖和存儲常式組成

3.14. 要啟用或禁用Performance Schema，可以將變數performance_schema設置為ON或OFF

3.15. 啟用或禁用performance_schema插樁

3.15.1. 使用setup_instruments表

3.15.1.1. 使用UPDATE語句更改instruments表的對應列值

3.15.2. 調用sys schema中的ps_setup_enable_instrument存儲過程

3.15.2.1. ps_setup_enable_instrument

3.15.2.2. ps_setup_disable_instrument

3.15.3. 使用performance-schema-instrument啟動參數

3.15.3.1. 變數支持performance-schema-instrument='instrument_name=value'這樣的語法

3.16. 啟用或禁用消費者表

3.16.1. 使用Performance Schema中的setup_consumers表

3.16.2. 調用sys     schema中的ps_setup_enable_consumer或ps_setup_disable_consuper存儲過程

3.16.3. 使用performance-schema-consumer啟動參數

3.17. 事務執行期間會一直持有元數據鎖

3.17.1. 要啟用元數據鎖監測，需要啟用wait/lock/meta-data/sql/mdl插樁

4. 升級MySQL

4.1. 新版本和穩定性之間的權衡

4.1.1. MySQL社區的長期成員Stewart Smith創造了著名的dot-20規則

4.1.2. 一款軟體在dot-20版本發佈之前永遠不會真正成熟。

4.2. 進行版本升級是一個有風險的過程

4.2.1. 包括備份所有數據、測試更改，然後運行升級過程

4.3. 大版本的升級可能會讓人望而卻步

4.4. 升級的原因

4.4.1. 安全漏洞

4.4.1.1. 隨著時間的推移，這種可能性會越來越小，但人們仍然有可能在MySQL中發現安全漏洞

4.4.2. 已知的bug

4.4.2.1. 在生產環境中遇到未知或無法解釋的行為時，我們建議你確定當前運行的MySQL版本，然後閱讀後續版本到最新版本的發佈說明

4.4.3. 新功能

4.4.3.1. MySQL並不總是遵循嚴格的主要（major）/次要（minor）/點（point）的版本發佈策略來添加功能

4.4.4. MySQL支持周期的終止

4.4.4.1. 建議保持在受支持的版本內，以便至少仍支持安全修複

4.5. 升級步驟

4.5.1. 制訂一個計劃

4.5.2. 閱讀該版本的發行說明，包括任何微小的更改

4.5.3. 閱讀官方文檔中的升級說明

4.5.4. 對新版本進行測試

4.5.5. 最後執行升級

4.6. 降級

4.6.1. 對於所有主要和次要的版本變更（例如，從8.0降級到5.7或從5.7降級到5.6），降級的唯一方法是恢復升級前的備份

4.6.2. 自從MySQL 8.0以來，不能再降級點發佈版本

4.6.3. 如果你運行的是8.0.25版本，除非導出所有數據並重新導入，否則不能再降級到8.0.24

4.7. 工具

4.7.1. Percona Toolkit提供的工具pt-upgrade

4.8. 最好的使用方法是首先使用慢速查詢日誌或二進位日誌收集最關註的查詢

4.9. 與直接登錄到每台伺服器相比，自動化可以使升級過程易於重覆，並且效率更高，而且因出現拼寫錯誤或者到錯誤的伺服器上執行升級而導致意外停機的概率也更低

5. Kubernetes

5.1. 在Kubernetes技術流行之前，許多公司要麼完全定製技術棧來供應和管理虛擬機和物理伺服器，要麼只完成了將資源生命周期管理一小部分的開源項目黏合在一起

5.2. MySQL不應該是在組織中Kubernetes上運行工作負載的第一個實驗對象