MySQL - 体系结构初探
文章目錄
- 生猛干貨
- 數據庫
- MySQL 主流分支
- MySQL 數據庫的體系結構
- Client Connectors 層
- MySQL Server 層
- 插件式的存儲引擎層
- 一條SQL的執行過程
- 雞肋的查詢緩存
- 搞定MySQL
生猛干貨
帶你搞定MySQL實戰，輕松對應海量業務處理及高并發需求，從容應對大場面試
數據庫
根據數據庫的類型或者功能或者數據庫的發展方向，可以把數據庫大致分成兩類
- 關系型數據庫
- 非關系性數據庫，或者叫 SQL 和 NoSQL
當然了關系型數據庫又可以分為傳統的關系型數據庫和 NewSQL
MySQL 主流分支
MySQL 從最初的 1.0、3.1 到后來的 5.x ,到今天的8.x，發生了各種各樣的變化。
被 Oracle 收購后，MySQL 的版本其實主要有幾個分支，除了需要付費的 MySQL 企業版本，還有很多 MySQL 社區版本。
主要有3個分支
- 第一條分支 MySQL 官方版本 ，目前已經到了8.0
- 第二個非常流行的開源分支版本叫 Percona Server，它是 MySQL 的技術支持公司 Percona 推出的，也是在實際工作中經常碰到的。Percona Server 在 MySQL 官方版本的基礎上做了一些補丁和優化，同時推出了一些工具。
- 另外一個非常不錯的版本叫 MariaDB，它是 MySQL 的公司被 Oracle 收購后，MySQL 的創始人 Monty 先生，按原來的思路重新寫的一套新數據庫，同時也把 InnoDB 引擎作為主要存儲引擎，也算 MySQL 的分支。
MySQL 數據庫的體系結構
接下來我們將重點來看下 InnoDB 存儲的原理和特點 。
以 MySQL 5.6 版本為例介紹 MySQL 體系的結構組成，以及 MySQL 5.7 版本和 MySQL 8.0 版本做了哪些優化和改進。
MySQL 體系結構由 Client Connectors 層、MySQL Server 層及存儲引擎層組成
Client Connectors 層
負責處理客戶端的連接請求，與客戶端創建連接。目前 MySQL 幾乎支持所有的連接類型，例如常見的 JDBC、Java、Python、Go 等。
MySQL Server 層
MySQL Server 層主要包括 Connection Pool、Service & utilities、SQL interface、Parser解析器、Optimizer 查詢優化器、Caches 緩存等模塊。
-
Connection Pool，負責處理和存儲數據庫與客戶端創建的連接，一個線程負責管理一個連接。Connection Pool 包括了用戶認證模塊，就是用戶登錄身份的認證和鑒權及安全管理，也就是用戶執行操作權限校驗。
-
Service & utilities 是管理服務&工具集，包括備份恢復、安全管理、集群管理服務和工具。
-
SQL interface，負責接收客戶端發送的各種 SQL 語句，比如 DML、DDL 和存儲過程等。
-
Parser 解析器會對 SQL 語句進行語法解析生成解析樹。
-
Optimizer 查詢優化器會根據解析樹生成執行計劃，并選擇合適的索引，然后按照執行計劃執行 SQL 語言并與各個存儲引擎交互。
-
Caches 緩存包括各個存儲引擎的緩存部分，比如：InnoDB 存儲的 Buffer Pool、MyISAM 存儲引擎的 key buffer 等，Caches 中也會緩存一些權限，也包括一些 Session 級別的緩存。
插件式的存儲引擎層
存儲引擎包括 MyISAM、InnoDB，以及支持歸檔的 Archive 和內存的 Memory 等。MySQL是插件式的存儲引擎，只要正確定義與 MySQL Server 交互的接口，任何引擎都可以訪問MySQL 。
存儲引擎底部是物理存儲層，是文件的物理存儲層，包括二進制日志、數據文件、錯誤日志、慢查詢日志、全日志、redo/undo 日志等。
一條SQL的執行過程
我們用一條 SQL SELECT 語句的執行軌跡來說明客戶端與 MySQL 的交互過程
-
①通過客戶端/服務器通信協議與 MySQL 建立連接。
-
②查詢緩存，這是 MySQL 的一個可優化查詢的地方，如果開啟了 Query Cache 且在查詢緩存過程中查詢到完全相同的 SQL 語句，則將查詢結果直接返回給客戶端；如果沒有開啟Query Cache 或者沒有查詢到完全相同的 SQL 語句則會由解析器進行語法語義解析，并生成解析樹。
-
③預處理器生成新的解析樹。
-
④查詢優化器生成執行計劃。
-
⑤查詢執行引擎執行 SQL 語句，此時查詢執行引擎會根據 SQL 語句中表的存儲引擎類型，以及對應的 API 接口與底層存儲引擎緩存或者物理文件的交互情況，得到查詢結果，由MySQL Server 過濾后將查詢結果緩存并返回給客戶端。若開啟了 Query Cache，這時也會將SQL 語句和結果完整地保存到 Query Cache 中，以后若有相同的 SQL 語句執行則直接返回結果。
雞肋的查詢緩存
說下這個查詢緩存 ，其實很雞肋的， 8.0已經默認去掉了查詢緩存。
因為查詢緩存往往弊大于利。查詢緩存的失效非常頻繁，只要有對一個表的更新，這個表上所有的查詢緩存都會被清空。因此很可能你費勁地把結果存起來，還沒使用呢，就被一個更新全清空了。對于更新壓力大的數據庫來說，查詢緩存的命中率會非常低。
一般建議在靜態表里使用查詢緩存，什么叫靜態表呢？就是一般我們極少更新的表。比如，一個系統配置表、字典表，那這張表上的查詢才適合使用查詢緩存。好在 MySQL 也提供了這種“按需使用”的方式。你可以將my.cnf參數 query_cache_type 設置成 DEMAND。
my.cnf #query_cache_type有3個值 0代表關閉查詢緩存OFF，1代表開啟ON，2（DEMAND）代表當sql語句中有SQL_CACHE關鍵詞時才緩存 query_cache_type=2這樣對于默認的 SQL 語句都不使用查詢緩存。而對于你確定要使用查詢緩存的語句，可以用 SQL_CACHE 顯式指定，像下面這個語句一樣：
mysql> select SQL_CACHE * from test where ID=5；查看當前mysql實例是否開啟緩存機制
mysql> show global variables like "%query_cache_type%";監控查詢緩存的命中率:
mysql> show status like'%Qcache%'; //查看運行的緩存信息- Qcache_free_blocks:表示查詢緩存中目前還有多少剩余的blocks，如果該值顯示較大，則說明查詢緩存中的內存碎片過多了，可能在一定的時間進行整理。
- Qcache_free_memory:查詢緩存的內存大小，通過這個參數可以很清晰的知道當前系統的查詢內存是否夠用，是多了，還是不夠用，DBA可以根據實際情況做出調整。
- Qcache_hits:表示有多少次命中緩存。我們主要可以通過該值來驗證我們的查詢緩存的效果。數字越大，緩存效果越理想。
- Qcache_inserts: 表示多少次未命中然后插入，意思是新來的SQL請求在緩存中未找到，不得不執行查詢處理，執行查詢處理后把結果insert到查詢緩存中。這樣的情況的次數，次數越多，表示查詢緩存應用到的比較少，效果也就不理想。當然系統剛啟動后，查詢緩存是空的，這很正常。
- Qcache_lowmem_prunes:該參數記錄有多少條查詢因為內存不足而被移除出查詢緩存。通過這個值，用戶可以適當的調整緩存大小。
- Qcache_not_cached: 表示因為query_cache_type的設置而沒有被緩存的查詢數量。
- Qcache_queries_in_cache:當前緩存中緩存的查詢數量。
- Qcache_total_blocks:當前緩存的block數量。
搞定MySQL
總結
以上是生活随笔為你收集整理的MySQL - 体系结构初探的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： MySQL- In 和 Exists的优
- 下一篇： MySQL - 存储引擎初探