Mysql8.0有着非常亮眼的新特性，其中之一便是数据字典的改变。
正如我们使用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: