正如我們使用mysql來存儲業務數據，同理，mysql自己也需要存放自己的數據，這部分即稱之為元數據。
在8.0之前，元數據是以.frm,PAR,OPT,TRN,TRG,isl這幾種文件形式或其他形式來存儲，這種元數據存儲方式在很多場景下成為了壹個瓶頸或者缺陷，就像下面提到的六點：
（註：frm:表元數據文件，存放表的定義，par:分區定義文件，db.opt:數據庫配置文件，isl：innodb符號文件，TRN,TRG：與觸發器相關的元數據文件）
1.information_schema的性能問題。
2.數據字典之間的不同步。在8.0之前，數據字典是處於壹個?腦裂?的狀態，這是因為innodb有自己的數據字典，server端也有自己的數據字典，這會導致某些元數據重復了，也會導致某些元數據的不壹致，所以我們需要壹個統壹的數據字典。如圖1。
3.某些元數據不僅以上面提到的幾種文件形式存放，還以MyISAM非事務型表存儲，這使得數據字典沒有統壹的格式，難以統壹管理。如下圖1.
圖1:8.0版本之前的元數據存放方式
4.不支持原子性DDL：壹個原子性DDL操作應該是這樣的：數據字典更新，存儲引擎層的操作，在binlog中記錄DDL操作。上面操作是原子性的，表示中間過程出現錯誤的時候，是可以完整回退的。這在8.0版本之前的DDL操作中是不支持的。因為數據庫元信息存放於元信息文件中、非事務性表中以及特定存儲引擎的數據字典中。這些都無法保證DDL操作內容在壹個事務當中，無法保證原子性。
5.崩潰恢復：由於DDL不是原子性的，有可能在DDL執行的中間階段crash，恢復起來就有點困難，並會對復制造成壹定的影響。
6.缺乏可擴展性：顯而易見，沒有統壹的數據字典，可擴展性明顯低了很多。
針對上面提及的這些點，mysql8.0版本推出了壹個事務型數據字典來替代以前元數據各種存儲方式。可以這麽說，8.0的數據字典把上面這些問題都解決了。
這就是8.0數據字典為什麽改變的原因。
reference:
/mysql-8-0-data-dictionary-background-and-motivation/
Mysql8.0數據字典系列壹：為什麽改變
標簽：問題特定bincode擴展性相關原因inf統壹