解析MySQL8.0新特性——事务性数据字典与原子DDL

吾爱主题阅读：271 2024-04-05 16:22:35 评论：0

前言

事务性数据字典与原子DDL，是MySQL 8.0推出的两个非常重要的新特性，之所以将这两个新特性放在一起，是因为两者密切相关，事务性数据字典是前提，原子DDL是一个重要应用场景。

MySQL 8.0之前的数据字典

MySQL 8.0之前的数据字典，主要由以下三部分组成：

（1）操作系统文件

db.opt：数据库元数据信息
frm：表元数据信息
par：表分区元数据信息
TRN/TRG：触发器元数据信息
ddl_log.log：DDL过程中产生的元数据信息

（2）mysql库下的非InnoDB系统表

（3）mysql库下的InnoDB系统表

我们可以看到，数据字典被分布到多个地方，一方面不利于元数据统一管理，另一方面容易造成数据的不一致(由于操作系统文件、非InnoDB系统表均不支持事务，执行DDL操作无法保证ACID)。

MySQL 8.0的数据字典

为了解决上述问题，MySQL 8.0将数据字典统一改进为InnoDB存储引擎存储，具体分为两部分：

（1）数据字典表：存放最重要的元数据信息，位于mysql库下，存储在mysql共享表空间(mysql.ibd)

（2）其他系统表：存放辅助的元数据信息，位于mysql库下，存储在mysql共享表空间(mysql.ibd)

数据字典表

数据字典表是不可见，既不能通过select访问，也不会出现在show tables或information.schema.tables结果里；尝试访问会报以下错误：

1 2	`mysql>` `select` `*` `from` `mysql.tables limit 10;` `ERROR 3554 (HY000): Access` `to` `data dictionary` `table` `'mysql.tables'` `is` `rejected.`

不过，在debug模式下，是可以访问这些隐藏的数据字典表的；我们重新编译安装(过程略)，并以debug模式启动进程，再次尝试访问，结果如下：

其他系统表

其他系统表，可以通过show tables或information_schema.tables查看，均以改进为InnoDB存储引擎(general_log、slow_log例外，这两张表并未记录元数据信息，只是用于记录日志)：

数据字典视图

刚刚提到，数据字典表只能在debug模式下访问，那么在生产环境中，我们应该怎么去获取元数据信息呢？答案是通过information_schema库下的数据字典视图。和Oracle数据库的设计理念一样，将元数据信息存放在基表中(x$、$)，然后通过视图(v$、dba_/all_/user_)的方式提供给用户查询；MySQL数据库也是如此，将元数据信息存放在mysql库的数据字典表中隐藏起来，然后提供information_schema库视图给用户查询：

数据字典缓存

为了减少磁盘IO，提高访问效率，MySQL 8.0引入了数据字典缓存。数据字典缓存是一块全局共享区域，通过LRU算法进行内存管理，具体包括：

1 2 3 4 5 6 tablespace definition cache partition：用于缓存表空间定义对象；大小限制由参数tablespace_definition_cache决定。 schema definition cache partition：用于缓存模式定义对象；大小限制由参数schema_definition_cache决定。 table definition cache partition：用于缓存表定义对象；大小限制由参数max_connections决定。 stored program definition cache partition：用于缓存存储过程定义对象；大小限制由参数stored_program_definition_cache决定。 character set definition cache partition：用于缓存字符集定义对象；硬编码限制256个。 collation definition cache partition：用于缓存排序规则定义对象；硬编码限制256个。

原子DDL

首先，了解一下什么是原子性？原子性是指，一个事务执行要么全部成功，要么全部失败。

在MySQL 8.0之前，由于不支持原子DDL，在服务进程异常挂掉或服务器异常宕机的情况下，有可能会导致数据字典、存储引擎结构、二进制日志之间的不一致。

在MySQL 8.0中，数据字典均被改造成InnoDB存储引擎表，原子DDL也被引入进来。原子DDL是将数据字典更新、存储引擎操作、二进制日志写入放到同一个事务里执行，要么全部成功提交，要么全部失败回滚。

接下来，我们还是先通过一个例子，来了解一下原子DDL。在这个例子中，DROP TABLE t1, t2属于同一个事务；在5.7版本中，出现了一个事务部分、成功部分失败的情况，即DROP TABLE t1成功、DROP TABLE t2失败；但在8.0版本中，因为DROP TABLE t2失败，导致整个事务全部失败回滚；这个例子就很好地体现了原子性和非原子性的区别。

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 5.7版本： mysql> CREATE TABLE t1 (c1 INT ); mysql> DROP TABLE t1, t2; ERROR 1051 (42S02): Unknown table 'test.t2' mysql> SHOW TABLES; Empty set (0.00 sec) 8.0版本： mysql> CREATE TABLE t1 (c1 INT ); mysql> DROP TABLE t1, t2; ERROR 1051 (42S02): Unknown table 'test.t2' mysql> SHOW TABLES; + ----------------+ | Tables_in_test | + ----------------+ | t1 | + ----------------+

在对原子DDL有初步了解后，接下来介绍一下具体过程：

（1）prepare：创建需要的对象，并将ddl日志写入到mysql.innodb_ddl_log；ddl日志记录了如何前滚和回滚ddl操作。
（2）perform：执行ddl操作。
（3）commit：更新数据字典并提交。
（4）post-ddl：重放和删除ddl日志。只有在实例异常宕机情况下，ddl日志才会继续保存在mysql.innodb_ddl_log；在在实例重启后，进行实例恢复阶段，ddl日志会重放和删除；如果第3步-数据字典更新已经成功提交，并写入redo log和binlog，那么ddl操作成功；否则，ddl操作失败，并根据ddl日志进行回滚

最后，再介绍一下，怎么查看DDL日志？

其中一个方法，是在debug级别下，访问表mysql.innodb_ddl_log进行查看(不推荐)

1 2 3 4 5 6 7 8 9 10 11 12 CREATE TABLE mysql.innodb_ddl_log ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY , thread_id BIGINT UNSIGNED NOT NULL , type INT UNSIGNED NOT NULL , space_id INT UNSIGNED, page_no INT UNSIGNED, index_id BIGINT UNSIGNED, table_id BIGINT UNSIGNED, old_file_path VARCHAR (512) COLLATE UTF8_BIN, new_file_path VARCHAR (512) COLLATE UTF8_BIN, KEY (thread_id) );

另一个办法，是可以将DDL日志打印到error log进行查看(推荐)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 mysql> set global innodb_print_ddl_logs= on ; Query OK, 0 rows affected (0.00 sec) mysql> set global LOG_ERROR_VERBOSITY=3; Query OK, 0 rows affected (0.00 sec) mysql> create table test(id int ); Query OK, 0 rows affected (0.04 sec) $ tail -100f mysql-error.log 2020-08-17T19:55:09.804345+08:00 73 [Note] [MY-012473] [InnoDB] DDL log insert : [DDL record: DELETE SPACE , id=57, thread_id=73, space_id=12, old_file_path=./test/test.ibd] 2020-08-17T19:55:09.804396+08:00 73 [Note] [MY-012478] [InnoDB] DDL log delete : 57 2020-08-17T19:55:09.816850+08:00 73 [Note] [MY-012477] [InnoDB] DDL log insert : [DDL record: REMOVE CACHE, id=58, thread_id=73, table_id=1069, new_file_path=test/test] 2020-08-17T19:55:09.816887+08:00 73 [Note] [MY-012478] [InnoDB] DDL log delete : 58 2020-08-17T19:55:09.820623+08:00 73 [Note] [MY-012472] [InnoDB] DDL log insert : [DDL record: FREE , id=59, thread_id=73, space_id=12, index_id=160, page_no=4] 2020-08-17T19:55:09.820673+08:00 73 [Note] [MY-012478] [InnoDB] DDL log delete : 59 2020-08-17T19:55:09.837695+08:00 73 [Note] [MY-012485] [InnoDB] DDL log post ddl : begin for thread id : 73 2020-08-17T19:55:09.837721+08:00 73 [Note] [MY-012486] [InnoDB] DDL log post ddl : end for thread id : 73