MySQL高级讲座篇之：MySQL 8.0 InnoDB新特性：字典表重构与日志系统的性能飞跃。 - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

各位观众老爷，晚上好！今天咱们聊聊MySQL 8.0里那些隐藏的“黑科技”，特别是InnoDB存储引擎的字典表重构和日志系统的性能飞跃。这俩玩意儿，听起来枯燥，但用好了，能让你的数据库跑得更快，更稳，就像给你的老牛车装上了火箭发动机！

开胃小菜：啥是字典表？为啥要重构它？

简单来说，字典表就是MySQL用来存各种元数据的地儿。啥叫元数据？就是描述数据的数据。比如，你的表叫啥名字？里面都有哪些字段？这些字段都是什么类型？用的什么字符集？这些信息统统都存在字典表里。

在MySQL 5.7及更早的版本里，字典表是以文件的形式存储在磁盘上的，也就是.frm文件。这种方式，优点是简单直接，缺点也很明显：

性能瓶颈： 每次访问元数据都要读写磁盘，速度慢得像蜗牛爬。
事务支持弱： .frm文件不支持事务，容易出现数据不一致的情况，尤其是在并发操作的时候。
锁竞争激烈： 多个线程同时访问同一个.frm文件，容易产生锁竞争，导致性能下降。

就好比你家有个小本本，上面记录着家里所有东西的摆放位置。每次找东西都要翻一遍这个本本，效率低下不说，万一几个人同时查，还会打起来（锁竞争）。

所以，MySQL 8.0痛定思痛，把字典表搬到了InnoDB存储引擎里，彻底告别了.frm文件。就像把那个小本本搬到了一个支持事务和并发访问的数据库里，速度嗖嗖的，再也不怕被打断了。

正餐：InnoDB字典表重构，都干了些啥？

这次重构，主要做了以下几件事：

元数据上云： 将所有元数据（表、列、索引、存储过程等等）都存储在InnoDB系统表里。
事务加持： 所有对元数据的修改都支持事务，保证ACID特性。
并发优化： 利用InnoDB的MVCC（多版本并发控制）机制，减少锁竞争，提高并发性能。
原子性DDL： DDL操作（比如CREATE TABLE、ALTER TABLE）要么完全成功，要么完全失败，不会留下半拉子工程。

具体来说，MySQL 8.0引入了一系列新的InnoDB系统表，用于存储各种元数据。下面列举一些重要的系统表：

系统表名	作用
`mysql.innodb_index_stats`	存储索引的统计信息，用于查询优化器选择最佳的执行计划。
`mysql.innodb_table_stats`	存储表的统计信息，包括行数、数据大小等等，同样用于查询优化器。
`mysql.tables`	存储关于表的信息，如表名、存储引擎、字符集等等。
`mysql.columns`	存储关于列的信息，如列名、数据类型、是否允许为空等等。
`mysql.indexes`	存储关于索引的信息，如索引名、索引类型、索引包含的列等等。
`mysql.routines`	存储关于存储过程和函数的信息，如名称、参数、返回值等等。
`mysql.parameters`	存储存储过程和函数的参数信息。
`mysql.events`	存储关于事件调度器的信息，用于定时执行任务。
`mysql.views`	存储关于视图的信息，如视图定义、权限等等。
`mysql.triggers`	存储关于触发器的信息，如触发器名称、触发时机、触发事件等等。
`mysql.table_spaces`	存储关于表空间的信息，包括表空间名称、文件路径等等。

这些系统表都使用InnoDB存储引擎，可以像普通表一样进行查询和管理。例如，你想查一下某个表的列信息，可以直接这样写：

SELECT
    column_name,
    data_type,
    column_type,
    is_nullable
FROM
    information_schema.columns
WHERE
    table_schema = 'your_database_name'
    AND table_name = 'your_table_name';

或者，你也可以直接查mysql.columns表：

SELECT
    column_name,
    data_type,
    column_type,
    is_nullable
FROM
    mysql.columns
WHERE
    table_schema = 'your_database_name'
    AND table_name = 'your_table_name';

注意，information_schema是一个虚拟数据库，它提供了一种更加友好的方式来访问元数据。实际上，information_schema中的数据也是从mysql数据库中的系统表里读取的。

甜点：日志系统性能飞跃，undo log和redo log的进化

除了字典表重构，MySQL 8.0还在日志系统上做了很多优化，主要集中在undo log和redo log这两个方面。

1. Undo Log瘦身：

Undo log是用来回滚事务的，保证事务的原子性。在MySQL 5.7及更早的版本里，undo log和redo log是混合在一起存储的。这种方式，会导致undo log占用大量的磁盘空间，影响性能。

MySQL 8.0将undo log单独存储在一个或多个undo表空间里，并且支持动态调整undo表空间的大小。这样，undo log就不会占用redo log的空间，也不会影响redo log的写入性能。

你可以通过以下参数来控制undo表空间：

innodb_undo_tablespaces: 指定undo表空间的数量，默认值为2。
innodb_undo_directory: 指定undo表空间的存储目录，默认值为数据目录。
innodb_undo_log_truncate: 启用undo log截断功能，定期回收不再使用的undo log空间。

要查看undo表空间的状态，可以使用以下命令：

SHOW GLOBAL STATUS LIKE 'Innodb_undo%';

2. Redo Log增强：

Redo log是用来保证事务的持久性的。在MySQL 8.0里，redo log也得到了增强，主要体现在以下几个方面：

更大的redo log buffer： 默认的redo log buffer大小增加到了16MB，可以减少redo log的写入次数，提高性能。
更好的redo log写入策略： 优化了redo log的写入策略，减少了磁盘IO，提高了写入速度。
支持动态调整redo log大小： 可以通过innodb_log_file_size参数动态调整redo log的大小，而无需重启服务器。

你可以通过以下参数来控制redo log：

innodb_log_file_size: 指定每个redo log文件的大小，默认值为48MB。
innodb_log_files_in_group: 指定redo log文件的数量，默认值为2。
innodb_log_buffer_size: 指定redo log buffer的大小，默认值为16MB。
innodb_flush_log_at_trx_commit: 指定redo log的刷新策略，有三个可选值：0、1、2。
- 0：每秒刷新一次redo log到磁盘，性能最好，但数据安全性最低。
- 1：每次事务提交都刷新redo log到磁盘，性能最差，但数据安全性最高。
- 2：每次事务提交都将redo log写入操作系统缓存，然后每秒刷新一次到磁盘，性能和数据安全性介于0和1之间。

要查看redo log的状态，可以使用以下命令：

SHOW GLOBAL STATUS LIKE 'Innodb_log%';

代码示例：动态调整redo log大小

假设你想把redo log的大小增加到256MB，可以按照以下步骤操作：

停止MySQL服务器：
```
sudo systemctl stop mysql
```
修改my.cnf配置文件：

在[mysqld] section添加以下配置：
```
innodb_log_file_size=256M
innodb_log_files_in_group=2
```
删除旧的redo log文件：

进入MySQL数据目录，删除ib_logfile0和ib_logfile1文件。
```
cd /var/lib/mysql  # 替换成你的数据目录
rm ib_logfile0 ib_logfile1
```
启动MySQL服务器：
```
sudo systemctl start mysql
```
MySQL会自动创建新的redo log文件。

注意事项：

调整redo log大小是一个比较危险的操作，一定要做好备份，以防万一。
调整redo log大小会影响数据库的恢复时间，redo log越大，恢复时间越长。
innodb_flush_log_at_trx_commit参数的选择要根据实际情况来决定，如果对数据安全性要求很高，可以选择1，如果对性能要求很高，可以选择0或2。

总结：

MySQL 8.0 InnoDB的字典表重构和日志系统性能飞跃，是两个非常重要的改进。它们可以显著提高数据库的性能和稳定性，让你的数据库跑得更快，更稳。

字典表重构： 告别.frm文件，元数据上云，事务加持，并发优化，原子性DDL。
Undo Log瘦身： 将undo log单独存储在undo表空间里，并且支持动态调整undo表空间的大小。
Redo Log增强： 更大的redo log buffer，更好的redo log写入策略，支持动态调整redo log大小。

记住，这些优化并不是免费的，它们会占用更多的磁盘空间和内存。所以，在配置这些参数的时候，一定要根据实际情况来决定，不要盲目追求性能。

课后作业：

查阅MySQL官方文档，了解更多关于InnoDB字典表重构和日志系统性能飞跃的细节。
在你的测试环境里，尝试调整redo log的大小，并观察对数据库性能的影响。
思考一下，如何在你的实际项目中，利用这些新特性来提高数据库的性能和稳定性。

好了，今天的讲座就到这里。希望大家有所收获，回去好好消化一下，争取早日成为MySQL高手！下次再见！

发表回复 取消回复

发表回复取消回复