tablestore列式存储原理_10分钟搞透：技术人必会的MySQL体系结构与存储引擎！
MySQL是目前使用最廣的開源數據庫，不管從裝機量、使用人群、專職人員、社區發展，還是基于MySQL的其他分支，都是當之無愧的No.1。
本文將從以下4個方面，帶你搞透MySQL體系結構與存儲引擎。
主要包括：
1、MySQL數據庫的體系結構；
2、MySQL支持的存儲引擎；
3、InnoDB能夠取代MyISAM的原因；
4、InnoDB幾大核心特性。
其中將重點介紹InnoDB存儲的原理和特點，以MySQL5.6版本為例介紹體系結構組成，以及MySQL5.7和MySQL8.0版本做了哪些優化和改進。
*閱讀本文需要10分鐘*
MySQL的體系結構
如下為MySQL數據庫的體系結構圖：
上面client connector部分負責處理客戶端的連接請求，與客戶端創建連接，目前MySQL幾乎支持所有的連接類型，例如常見的JDBC、Python、GO等。
下面就是MySQL Server部分，這里包括connection pool，數據庫給客戶端創建的連接都在這里處理和存儲，用一個線程管理一個連接，包括了用戶認證：也就是用戶登錄身份的認證和鑒權和安全管理：就是用戶執行操作權限校驗。
service utilities是管理服務&工具集，包括備份恢復、安全管理、集群管理服務和工具。
旁邊是SQL處理所需要的功能模塊了，包括SQL interface，負責接收客戶端來的各種SQL語句比如DML、DDL和存儲過程等；Parser是SQL解析器會對SQL進行語法解析生成解析樹；還有optimizer，查詢優化器，它會根據解析樹生成執行計劃，選擇合適的索引，之后會按照執行計劃去執行SQL與各個存儲引擎交互；Caches緩存包括各個存儲引擎的緩存部分，比如InnoDB存儲有buffer pool，MyISAM存儲引擎有key buffer等，也會緩存一些權限，也包括一些session級別的緩存。
再下面是MySQL所支持的各個存儲引擎，這里只是舉例寫了一些。有最原始的MyISAM，以及InnoDB、支持歸檔的Archive和內存的Memory等。MySQL是插件式的存儲引擎，只要寫好跟MySQL Server的接口，任何引擎都可以進入MySQL里來，這也是MySQL流行的原因之一，如極數云舟的ArkDB 本質上也是了MySQL的一個引擎，在使用的時候可以用Alter table engines=ArkDB來修改之前的表為ArkDB。
最下面是物理存儲層，是文件的物理存儲，包括二進制日志、數據文件、錯誤日志、慢查詢日志、全日志，redo/undo日志等。
例：用一個SQL的執行軌跡來說明客戶端與MySQL的交互過程。
客戶端發起一個Select語句：
第1步會通過客戶端/服務器通信協議與MySQL建立連接；
第2步查詢緩存，這是MySQL的一個優化查詢的地方；
- 如果開啟了query cache且在查詢緩存中有完全相同的SQL，則會直接返回查詢結果給客戶端；
- 如果沒有開啟query cache或者沒有找到完全相同的SQL則會經歷解析器進行語法語義解析，生成解析樹；
第3步會到預處理器生成新的解析樹；
第4步查詢優化器，生成執行計劃；
第5步查詢執行引擎去真正執行SQL，此時會根據SQL中表的存儲引擎類型，對應的API接口與底層存儲引擎緩存或者物理文件交互，得到查詢結果，由MySQL Server過濾后緩存起來并返回給客戶端。若開啟了query cache，這時也會將SQL語句和結果完完全全的保存到query cache中，以后若有相同SQL執行會直接返回結果。
同理可思考， insert和update語句的執行流程是怎么樣的，有哪些不同。當然，這類DML語句可能會復雜一些。
MySQL支持的存儲引擎
存儲引擎就是MySQL中具體與文件打交道的子系統，它是根據MySQL AB公司提供的文件訪問層抽象接口來定制的一種文件訪問機制，這種機制就叫存儲引擎。
1.常用的存儲引擎
下圖是常用的一些存儲引擎：
有遠古時期的MyISAM、支持事務的InnoDB、內存類型的Memory、以及歸檔類型的Archive、列式存儲的Infobright，以及一些新興的存儲引擎，以rocksdb為底層基礎的MyRocks和RocksDB，和以分形樹索引組織存儲的TokuDB，當然現在還有極數云舟出品的分布式存儲引擎ArkDB。
在MySQL5.6版本之前，默認的存儲引擎都是MyISAM，但5.6之后默認的存儲引擎就是InnoDB了。
2.MySQL InnoDB存儲引擎的大體架構
下圖為是InnoDB存儲引擎的具體架構圖：
上半部分是實例層（計算層），在內存里，下半部分是物理層，位于文件系統中。
1）實例層
分為線程和內存。InnoDB重要的線程有master thread，是InnoDB的主線程，負責調度其他各線程。
Master thread優先級最高, 其內部包含幾個循環：主循環(loop),后臺循環(background loop),刷新循環(flush loop),暫停循環(suspend loop)。master thread會根據其內部運行的相關狀態在各循環間中進行切換。
大部分操作在主循環(loop)中完成,其包含有1s和10s兩種操作。
1s操作主要包括：
10s操作主要包括：
- buf dump thread負責將buffer pool中的內容dump到物理文件中，以便再次啟動MySQL時加載進來，快速加熱數據；
- page cleaner thread負責將buffer pool中的臟頁刷新到磁盤，在5.6版本之前沒有這個線程，刷新操作都是由主線程完成的，所以在刷新臟頁時會非常影響MySQL的處理能力，在5.7版本之后可以通過參數設置開啟多個page cleaner線程工作；
- purge thread負責將不再使用的undo日志進行回收；
- read thread處理用戶的讀請求，并負責將數據頁從磁盤上讀出來，可以通過參數設置線程數量；
- write thread負責將數據頁從緩沖區寫出到磁盤，也可以通過參數設置線程數量，page cleaner線程發起刷臟頁操作后write thread就開始工作了；
- redo log thread負責把日志緩沖中的內容刷新到redo log文件中；
- insert buffer thread負責把insert buffer中的內容刷新到磁盤。
內存部分主要有InnoDB buffer pool，這里包含InnoDB最重要的緩存內容。數據和索引頁、undo頁、insert buffer頁、自適應hash索引頁、數據字典頁和鎖信息等。additional memory pool后續已不再使用。redo buffer里面存儲數據修改所產生的redo log。double write buffer是double write所需的buffer，主要解決由于宕機引起物理寫入操作中斷，數據頁不完整的情況。
2）物理層
邏輯上分為系統表空間、用戶表空間和redo日志。系統表空間里有文件ibdata，和一些undo，ibdata文件里有insert buffer段、double write段、回滾段、索引段、數據字典段和undo信息段。
用戶表空間是指.ibd后綴的文件，里面有insert buffer的bitmap頁、葉子頁（這里存儲真正的用戶數據）、非葉子頁，InnoDB表是索引組織表，采用B+樹組織存儲，數據都存儲在葉子節點中，分支節點（即非葉子頁）存儲索引分支查找的數據值。
redo中包括多個redo文件，這些文件循環使用，當達到一定存儲閾值時會觸發checkpoint刷臟頁操作，同時也在MySQL實例異常宕機后重啟，InnoDB表數據自動還原恢復過程中使用。
3.MySQL InnoDB存儲引擎的內存和物理結構
以MySQL 5.6為例，InnoDB存儲引擎體系結構如下圖：
用戶讀取或者寫入的最新數據都在buffer pool中，如果buffer pool中沒有會讀取物理文件查找，之后放到buffer pool中并返回給MySQL Server。buffer pool采用LRU機制，具體的內存隊列和刷新機制不詳細描述。
buffer pool決定了一個SQL執行的快慢，如果查詢結果頁都在內存中則返回很快，否則會產生物理讀（磁盤讀），性能遠不如內存，則返回時間變長。但又不能將所有數據頁都放到buffer pool中，比如物理文件ibd文件有500GB，機器不可能配置能容得下500GB數據頁的內存，成本很高而且也沒必要。單機單實例情況下，可以配置buffer pool為物理內存的60%-80%，剩余內存用于session產生的sort和join等以及運維管理使用。如果是單機多實例，所有實例的buffer pool總量也不要超過物理內存的80%。開始時可以通過經驗設置一個buffer pool的經驗值比如16GB，之后業務在MySQL運行一段時間后可以根據show global status like '%buffer_pool_wait%'的值來看是否需要調整buffer pool的大小。
redo log是一個循環復用的文件集，負責記錄InnoDB中所有對Buffer Pool的物理修改日志，當redo log文件空間中，檢查點位置的LSN和最新寫入的LSN差值（checkpoint_age）達到redo log文件總空間的75%后，InnoDB會進行異步刷新操作，直到降到75%一下，并釋放出redo log的空間；當checkpoint_age達到文件總量大小的90%后，會觸發同步刷新，此時InnoDB是掛起的無法操作。
這樣就得出redo log的大小直接影響了數據庫的處理能力，如果設置太小會導致強行checkpoint操作頻繁刷新臟頁，那就需要設置的大一些，5.6版本之前redo log總大小不能超過3.8GB，5.7之后放開了這個限制。
事務提交時log buffer會刷新到redo log文件中，具體刷新機制由參數控制，可以根據自身業務特點配置。
- 若參數innodb_file_per_table=ON，則表示用戶建表采用用戶獨立表空間，即一個表對應一組物理文件，.frm表定義文件和.ibd表數據文件。
- 若這個參數設置為OFF，則用戶建表就存儲在ibdata文件中，不建議采用共享表空間，這樣會導致ibdata文件過大，而且當表刪除后空間無法回收。獨立表空間可以在用戶刪除大量數據后回收物理空間，執行一個DDL就可以將表空間的高水位降下來了。
4. 關于MySQL 5.7和8.0的一些新特點
- 5.7中將undo從共享表空間ibdata文件中分離出來，可以在安裝MySQL時由用戶自行指定文件大小和數量；
- 5.7中還增加了temporary臨時表空間，里面存儲著臨時表或者臨時查詢結果集的數據；
- 5.7版本開始，buffer pool大小可以動態修改，無需重啟數據庫實例，這是DBA的福音；
- 8.0中將InnoDB表的數據字典和undo都從共享表空間ibdata中徹底分離出來了，以前需要ibdata文件中數據字典與獨立表空間ibd文件中數據字典一致才行，8.0中就不需要了；
- temporary臨時表空間也可以配置多個物理文件了，而且均為InnoDB存儲引擎并能創建索引，這樣加快了處理的速度；
- 現在用戶還可以像oracle數據庫那樣設置一些表空間，每個表空間對應多個物理文件，每個表空間都可以給多個表使用，但一個表只能存儲在一個表空間中。
InnoDB能取代MyISAM的原因
對比幾個主流的存儲引擎，本文主要講解MyISAM和InnoDB的對比。
1、功能對比
InnoDB和MyISAM的對比如下圖表：
- InnoDB支持ACID的事務4個特性，而MyISAM不支持；
- InnoDB支持4種事務隔離級別，默認是可重復讀repeatable read，MyISAM不支持；
- InnoDB支持crash安全恢復，MyISAM不支持；InnoDB支持外鍵，MyISAM不支持；
- InnoDB支持行級別的鎖粒度，MyISAM不支持，只支持表級別的鎖粒度；
- InnoDB支持MVCC，MyISAM不支持。
- InnoDB特性上，InnoDB表最大可以64TB，支持聚簇索引、支持壓縮數據存儲，支持數據加密，支持查詢/索引/數據高速緩存，支持自適應hash索引、空間索引，支持熱備份和恢復等。
2、性能對比
InnoDB也完勝MyISAM
讀寫混合模式下，隨著CPU核數的增加，InnoDB的讀寫能力呈線性增長，在這個測試用例里，最高可達近9000的TPS，但MyISAM因為讀寫不能并發，它的處理能力跟核數沒關系，呈一條水平線，TPS低于500。
只讀模式下，隨著CPU核數的增加，InnoDB的讀寫能力呈線性增長，最高可達近14000的TPS，但MyISAM的處理能力不到3000。
以上測試僅為說明InnoDB比MyISAM的處理能力強大，具體TPS測試數據跟硬件和測試條件不同而有很大差異。
InnoDB的幾大核心性能
InnoDB存儲引擎的核心特性包括這些：MVCC、鎖、鎖算法和分類、事務、表空間和數據頁、內存線程以及狀態查詢。
具體思維導圖如下，建議多下功夫重點研究：
重點說明ARIES三原則。它是指Write Ahead Logging（WAL），即先寫日志后寫磁盤，日志成功寫入后事務就不會丟，后續由checkpoint機制來保證磁盤物理文件與redo日志達到一致性；
利用Redo來記錄變更后的數據，即redo里記錄事務數據變更后的值；
利用Undo來記錄變更前的數據，即undo里記錄事務數據變更前的值，用于回滾和其他事務多版本讀。
show engine innodb statusG的結果里面有詳細的InnoDB運行態信息，分段記錄的，包括內存、線程、信號、鎖、事務等，請你多多使用，出現問題時從中能分析出具體原因和解決方案。
總結
以上是生活随笔為你收集整理的tablestore列式存储原理_10分钟搞透：技术人必会的MySQL体系结构与存储引擎！的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： TQ210——下载总结
- 下一篇： mysql中修改表字段的类型长度_mys