MySQL8.0 • 引擎特性 • 关于undo表空间的一些新变化

摘要： Note: 当前版本为MySQL8.0.3 InnoDB的undo log是其实现多版本的关键组件，在物理上以数据页的形式进行组织。在早期版本中(<5.6)，undo tablespace是在ibdata中，因此一个常见的问题是由于大事务不提交导致ibdata膨胀，这时候通常只有重建数据库一途来缩小空间。

Note: 当前版本为MySQL8.0.3

InnoDB的undo log是其实现多版本的关键组件，在物理上以数据页的形式进行组织。在早期版本中(<5.6)，undo tablespace是在ibdata中，因此一个常见的问题是由于大事务不提交导致ibdata膨胀，这时候通常只有重建数据库一途来缩小空间。到了MySQL5.6版本， InnoDB开始支持独立的undo tablespace，也就是说，undo log可以存储于ibdata之外。但这个特性依然鸡肋：

首先你必须在install实例的时候就指定好独立Undo tablespace, 在install完成后不可更改。

Undo tablepsace的space id必须从1开始，无法增加或者删除undo tablespace。

到了MySQL5.7版本中，终于引入了一个期待已久的功能：即在线truncate undo tablespace。DBA终于摆脱了undo空间膨胀的苦恼。

在MySQL8.0，InnoDB再进一步，对undo log做了进一步的改进：

无需从space_id 1开始创建undo tablespace，这样解决了In-place upgrade或者物理恢复到一个打开了Undo tablespace的实例所产生的space id冲突。不过依然要求undo tablespace的space id是连续分配的（fsp_is_undo_tablespace）, space id的范围为(0xFFFFFFF0UL - 128, 0xFFFFFFF0UL - 1) (Bug #23517560)

从8.0.3版本开始，默认undo tablespace的个数从0调整为2，也就是在8.0版本中，独立undo tablespace被默认打开。修改该参数为0会报warning并在未来不再支持(WL#10583)

允许动态的增加undo tablespace的个数，也就是说可以动态调整innodb_undo_tablespaces。当调大该参数时，会去创建新的undo tablespace。但如果设小该值，则仅仅是不实用多出来的Undo tablespace，目前不会去主动删除它们(innodb_undo_tablespaces_update), WL#9507

Undo tablespace的命名从undoNNN修改为undo_NNN

和以前版本最大的不同之处就是，在8.0之前只能创建128个回滚段，而在8.0版本开始，每个Undo tablespace可以创建128个回滚段，也就是说，总共有innodb_rollback_segments * innodb_undo_tablespaces个回滚段。这个改变的好处是在高并发下可以显著的减少因为分配到同一个回滚段内的事务间产生的锁冲突

Innodb_undo_truncate参数默认打开，这意味着默认情况下，undo tablespace超过1GB（参数innodb_max_undo_log_size来控制）时，就会触发online truncate

支持undo tablespace加密( 参考文档)

在ibdata中保留的32个slot原本用于临时表空间的回滚段，但事实上他们并没有做任何的持久化，因此在8.0中直接在内存中为其创建单独的内存结构，这32个slot可以用于持久化的undo回滚段(Bug #24462978)!

本文为云栖社区原创内容，未经允许不得转载，如需转载请发送邮件至[email protected]；如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件至：[email protected] 进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容。

原文链接