MySQL8。0数据字典表

　　MySQL8。0对数据字典进行了重构，用户表、数据字典表、MySQL其它系统表的元数据都统一保存到mysql库的数据字典表中了。
　　mysql库中，除了generallog、slowlog2个日志表，其它所有表的存储引擎都是InnoDB，伴随而来的是DDL终于能够支持原子操作了。
　　以DROPTABLEt1，t2为例，不会出现t1表删除成功，t2表删除失败的情况，而是要么都删除成功，要么都删除失败。
　　本文我们就来聊聊MySQL8。0中的数据字典表。
　　本文内容基于MySQL8。0。29源码。
　　目录1。概述2。数据字典表有哪些？3。数据字典表元数据在哪里？4。创建数据字典表5。打开数据字典表6。总结
　　正文1。概述
　　MySQL8。0重构数据字典之后，废除了MySQL5。7中用于保存元数据的磁盘文件：。frm、。par、。TRN、。TRG、。isl、db。opt、ddllog。log。
　　如果想要了解上面这些磁盘文件都保存了什么元数据，可以参照MySQL官方文档：https：dev。mysql。comdocrefman8。0endatadictionaryfileremoval。html
　　这些文件被废除之后，原本保存到这些文件中的元数据，都保存到数据字典表中了。
　　数据字典表本身也大变样了：数据字典表不再位于InnoDB系统表空间，而是迁移到mysql库中，mysql库位于mysql表空间，磁盘文件为mysql。ibd。SYSTABLES、SYSCOLUMNS、SYSINDEXES、SYSFIELDS这4个数据字典表也不再完全依赖硬编码在源码中的元数据了，而是和其它表一样，使用保存在mysql库的数据字典表中的元数据。
　　上面4个数据字典表的名字也发生了变化，后面会介绍。2。数据字典表有哪些？
　　按照官方文档的定义，MySQL8。0一共有31张数据字典表：ddpropertiesinnodbddllogcatalogscharactersetscheckconstraintscollationscolumnstatisticscolumntypeelementscolumnseventsforeignkeycolumnusageforeignkeysindexcolumnusageindexpartitionsindexstatsindexesparametertypeelementsparametersresourcegroupsroutinesschematastspatialreferencesystemstablepartitionvaluestablepartitionstablestatstablestablespacefilestablespacestriggersviewroutineusageviewtableusage
　　上面只是简单列出了数据字典表的表名，如果想了解每个表存放了什么内容，可以参照官方文档：https：dev。mysql。comdocrefman8。0ensystemschema。html
　　默认情况下，我们是看不到数据字典表的，需要满足以下条件才能看到：源码编译Debug版本MySQL，以使用cmake编译为例，需要带上DCMAKEBUILDTYPEDebug编译选项。连接MySQL之后，先执行下面的SQL告诉MySQL跳过数据字典表的权限检查：SETSESSIONdebugd，skipddtableaccesscheck
　　满足以上2个条件之后，执行下面这条SQL就可以看到所有数据字典表了：SELECTa。nameASdbname，b。FROMmysql。schemataASaINNERJOINmysql。tablesASbONa。idb。schemaidWHEREb。schemaid1ANDb。hiddenSystemORDERBYb。id
　　执行上面的SQL列出来的表有32个，其中innodbdynamicmetadata表不属于数据字典表。
　　上面列出的数据字典表中，有4个需要重点介绍，因为不管是数据字典表本身，还是用户表，都离不开这4个表：tables：存储表的元数据，包括表空间ID、数据库ID、表ID、表名、表注释、行格式等信息，对应MySQL5。7中的数据字典表SYSTABLES。columns：存储表中字段的元数据，包括表ID、字段ID、字段名、字段注释、字段类型、是否自增等信息，对应MySQL5。7中的数据字典表SYSCOLUMNS。indexes：存储表的索引元数据，包括表空间ID、表ID、索引ID、索引名、索引注释、是否是隐藏索引等信息，对应MySQL5。7中的数据字典表SYSINDEXES。indexcolumnusage：存储索引中字段的元数据，包括索引ID、字段ID、字段在索引中的编号（从1开始）、索引字段长度（如果是前缀索引字段，则是前缀的长度）、索引字段排序、是否隐藏，共6个字段，对应MySQL5。7中的数据字典表SYSFIELDS。
　　这个表中没有包含更详细的字段信息，如果需要，可以通过字段ID到columns表获取。
　　indexcolumnusage和SYSFIELDS表不完全一样，有2点需要说明：indexcolumnusage包含6个字段，比SYSFIELDS多3个字段：
　　order：表示索引字段的排序。
　　length：hidden0时，表示索引字段长度，或前缀索引字段的前缀长度；hidden1时，字段值为NULL。
　　hidden：0表示索引中该字段由用户定义；1表示索引中该字段是MySQL给加上的。以下是一个测试表，图中name是从columns表中连表查询得到的，其它都是indexcolumnusage表的字段。CREATETABLEt5（idintunsignedNOTNULLAUTOINCREMENT，str1varchar（255）CHARACTERSETutf8mb3COLLATEutf8generalciNOTNULLDEFAULT，i1intNOTNULLDEFAULT0，str2varchar（255）CHARACTERSETutf8mb3COLLATEutf8generalciNOTNULLDEFAULT，i2intNOTNULLDEFAULT0，PRIMARYKEY（id）USINGBTREE，UNIQUEKEYidxi1（i1）USINGBTREE，KEYidxstr1（str1）USINGBTREE）ENGINEInnoDBDEFAULTCHARSETutf8mb3；
　　indexid310是主键索引，hidden0的记录是主键字段；hidden1的记录是主键索引中的其它字段，也就是表中的字段。
　　indexid312是二级索引，其中str1是前缀索引字段，前缀长度为2553（utf8一个字符最多占用的字节数）765，hidden0表示str1是用户定义的二级索引字段；hidden1的记录是MySQL自己增加到二级索引中的主键字段。indexcolumnusage表中的ordinalposition表示编号，从1开始；SYSFIELDS中的POS表示序号，从0开始。
　　除了在Debug版本的MySQL中设置跳过数据字典表的权限检查之外，还可以通过informationschema数据库中的表或视图查看其对应的数据字典表：
　　数据字典表informationschema表或视图tablesINNODBTABLEScolumnsINNODBCOLUMNSindexesINNODBINDEXESindexcolumnusage
　　INNODBFIELDS
　　3。数据字典表元数据在哪里？
　　数据字典表用于存储用户表的元数据，这个比较好理解，因为创建用户表的时候，所有数据字典表都已经存在了，把用户表的各种元数据插入到相应的数据字典表就可以了。
　　数据字典表本身的元数据也会保存到数据字典表里，但是某个数据字典表创建的时候，有一些数据字典表还没有创建，这就有问题了。
　　我们以columns、indexes这2个数据字典表为例来说明：columns表先于indexes表创建，columns表创建成功之后，需要把索引元数据保存到indexes表中，而此时indexes表还没有创建，columns表的索引元数据自然也就没办法保存到indexes表中了。
　　MySQL解决这个问题的方案是引入一个中间层，用于临时存放所有数据字典表的各种元数据，等到所有数据字典表都创建完成之后，再把临时存放在中间层的所有数据字典表的元数据保存到相应的数据字典表中。
　　这里所谓的中间层实际上是一个存储适配器，源码中对应的类名为Storageadapter，这是一个实现了单例模式的类。
　　MySQL在初始化数据目录的过程中，Storageadapter类的实例属性mcoreregistry就是所有数据字典表元数据的临时存放场所。4。创建数据字典表
　　我们安装MySQL完成之后，想让MySQL运行起来，要做的第一件事就是初始化MySQL，实际上就是初始化MySQL数据目录。
　　初始化过程会创建MySQL运行时需要的各种表空间、数据库、表，其中就包含数据字典表。
　　创建数据字典表的过程分为3个步骤进行：
　　第1步，把代表每个数据字典表的Objecttable对象注册到Systemtables类的实例属性mregistry中。
　　除了数据字典表，mregistry中还包含了mysql库中的其它MySQL系统表。
　　第2步，循环mregistry中的所有表，通过Objecttable得到数据字典表的DDL，然后调用dd：：executequery（）执行DDL语句创建数据字典表。
　　dd：：executequery（）创建数据字典表的过程中，会把表的元数据临时存放到Storageadapter类的实例属性mcoreregistry中，而不会保存到各种元数据对应的数据字典表中，这么做的原因在上一小节中介绍数据字典表的元数据在哪里时，已经介绍过了，这里不再赘述。
　　dd：：executequery（）执行完一个数据字典表的DDL语句之后，这个数据字典表在表空间中就已经存在了，mregistry中的所有表都处理完成之后，所有数据字典表就都存在了。
　　第3步，循环mregistry中的所有表，把每个表本身的元数据（数据库ID、表ID、表名、注释、字段数量等）保存到mysql。tables数据字典表中，然后把表的字段、索引等元数据保存到对应的数据字典表中。
　　所有数据字典表的元数据都从Storageadapter类的实例属性mcoreregistry中读取。
　　经过3个步骤的通力协作，所有数据字典表的元数据就都保存到数据字典表中了，这个鸡生蛋、蛋生鸡的问题，就这样通过引入外力（mcoreregistry）解决了。5。打开数据字典表
　　数据字典表保存着MySQL运行过程中需要的一系列关键数据，使用频次很高，MySQL启动过程中就会把数据字典表的元数据都加载到内存中，这就是打开表的过程。
　　也就是说，打开数据字典表是在MySQL启动过程中完成的。
　　前面我们介绍过，数据字典表的元数据也是保存在数据字典表中的。
　　MySQL启动过程中，要先打开数据字典表才能拿到数据字典表的元数据，而要拿到数据字典表的元数据，又必须先打开数据字典表。
　　这个过程很绕，不是很好理解，我们来打个比方：数据字典表是一个房间，数据字典表的元数据是打开房间门的钥匙。
　　现在问题来了，因为MySQL把数据字典表的元数据保存在数据字典表中，这就相当于把打开房间门的钥匙落在房间里了。
　　要想打开房间，必须先拿到钥匙，而要想拿到钥匙又必须先打开房间，这样一转换，问题是不是更好理解点了？
　　我们先来想想怎么解决房间和钥匙问题，如果把打开房间的钥匙落在房间里了，有哪些办法可以解决？
　　我能想到的有以下3种解决方案：暴力破解，把锁撬开。找专业的开锁师傅把锁打开。用备用钥匙开门。这个方法最好，但是有个前提条件：已经提前准备好了备用钥匙。
　　MySQL里没有前2种方案，而是留了一把备用钥匙，也就是第3种方案，接下来我们看看MySQL打开数据字典表的过程：
　　第1步，和创建数据字典表一样，把代表每个数据字典表的Objecttable对象注册到Systemtables类的实例属性mregistry中。
　　每个数据字典表的Objecttable对象中，都定义了这个表的表名、字段、索引、外键等信息。
　　Objecttable对象中保存的并不是DDL语句，却类似于我们建表时的DDL语句。
　　下面这个例子是源码中表空间数据字典表mysql。tablespacesObjecttable对象中定义的该表的信息：Tablespaces：：Tablespaces（）｛表名mtargetdef。settablename（tablespaces）；字段mtargetdef。addfield（FIELDID，FIELDID，idBIGINTUNSIGNEDNOTNULLAUTOINCREMENT）；mtargetdef。addfield（FIELDNAME，FIELDNAME，nameVARCHAR（268）NOTNULLCOLLATEStringtype（Objecttabledefinitionimpl：：namecollation（）mcollname））；mtargetdef。addfield（FIELDOPTIONS，FIELDOPTIONS，optionsMEDIUMTEXT）；mtargetdef。addfield（FIELDSEPRIVATEDATA，FIELDSEPRIVATEDATA，seprivatedataMEDIUMTEXT）；mtargetdef。addfield（FIELDCOMMENT，FIELDCOMMENT，commentVARCHAR（2048）NOTNULL）；mtargetdef。addfield（FIELDENGINE，FIELDENGINE，engineVARCHAR（64）NOTNULLCOLLATEutf8generalci）；mtargetdef。addfield（FIELDENGINEATTRIBUTE，FIELDENGINEATTRIBUTE，engineattributeJSON）；索引mtargetdef。addindex（INDEXPKID，INDEXPKID，PRIMARYKEY（id））；mtargetdef。addindex（INDEXUKNAME，INDEXUKNAME，UNIQUEKEY（name））；如果有外键等其它信息，也会加在这里｝
　　第2步，循环mregistry中的所有表，通过Objecttable得到数据字典表的DDL，然后调用dd：：executequery（）执行DDL语句创建数据字典表。
　　和创建数据字典表中的第2步不一样，dd：：executequery（）执行DDL，并不会真正的创建表，只是为了生成数据字典表元数据，并把元数据保存到Storageadapter类的实例属性mcoreregistry中。
　　保存到mcoreregistry中的数据字典表元数据，就是我们前面说的备用钥匙，有了这把备用钥匙，就能打开数据字典表了。
　　第3步，循环mregistry中的所有表，通过第2步生成的数据字典表元数据，去mysql表空间中（表空间文件：mysql。ibd）读取各个数据字典表的元数据。
　　这一步执行完成之后，所有数据字典表的元数据都被加载到内存中了，数据字典表都被打开了。
　　第4步，循环mregistry中的所有表，把数据字典表的元数据从mcoreregistry删除。
　　第5步，循环mregistry中所有的表，把从表空间中读取出来的数据字典表的元数据存入mcoreregistry中。
　　不过，这一步存入mcoreregistry的并不是所有数据字典表的元数据，而是22个核心（CORE）数据字典表的元数据：catalogscharactersetscheckconstraintscollationscolumnstatisticscolumntypeelementscolumnsforeignkeycolumnusageforeignkeysindexcolumnusageindexpartitionsindexesresourcegroupsschematatablepartitionvaluestablepartitionstablestablespacefilestablespacestriggersviewroutineusageviewtableusage
　　15步执行完成之后，mcoreregistry中就只包含上面22个核心数据字典表的元数据了，有了这些表的元数据，就可以打开其它所有表了。
　　第6步，调用dd：：executequery（）执行FLUSHTABLES关闭已经打开的所有数据字典表、非数据字典表，后续就可以用从数据字典表中读取出来的元数据来打开数据字典表和其它所有需要的表了。
　　到这里，打开数据字典表的大体流程就已经介绍完了，也许大家会有疑问：
　　第2步调用dd：：executequery（）执行DDL，已经拿到了数据字典表的元数据。
　　为了区分，把这里拿到的元数据叫作备用元数据。
　　第3步根据备用元数据打开数据字典表，从表空间中读取到数据字典表的元数据。
　　同样为了区分，把这里拿到的元数据叫作原配元数据。
　　第4步从mcoreregistry中删除备用元数据。第5步把原配元数据存入mcoreregistry。
　　数据字典表的备用元数据和原配元数据不是一样的吗？为什么还要用原配元数据替换备用元数据，这是不是多此一举？
　　我没有逐个对比备用元数据和原配元数据是否完全一样，这是个不小的工程。不过，既然源码中这么实现，那应该是有它的原因，只是我还没有发现。如果后面发现其中的原因，我会再补充到我的博客中。6。总结
　　要理解MySQL8。0中的数据字典表，核心是理解以下2点：初始化数据目录时，数据字典表的元数据是怎么存放到数据字典表中的？
　　这主要是借助了Storageadapter类实例的mcoreregistry属性。
　　在创建数据字典表的过程中，先创建每个数据字典表，并把元数据临时存放到mcoreregistry中，所有数据字典表都创建成功之后，最后再一次性把所有数据字典表的元数据保存到对应的数据字典表中。MySQL启动时，怎么用数据字典表的元数据打开数据字典表？
　　这同时借助了硬编码在源码中的数据字典表定义，以及Storageadapter类实例的mcoreregistry属性。
　　MySQL启动过程中，先通过Objecttable得到创建数据字典表的DDL，调用dd：：executequery（）执行DDL，拿到元数据（备用原数据），把备用元数据临时存放到mcoreregistry属性中，再通过备用元数据打开数据字典表。