MySQL DBA 需要了解一下 InnoDB Online DDL 算法更新
在 MySQL 8.0.12 中,我们引入了一种新的 DDL 算法,该算法在更改表的定义时不会阻塞表。第一个即时操作是在表格末尾添加一列,这是来自腾讯游戏的贡献。
然后在 MySQL 8.0.29 中,我们添加了在表中任意位置添加(或删除)列的可能性。
在这篇文章中,我想重点讨论盲目使用此功能时可能发生的一些危险。
默认算法
从 MySQL 8.0.12 开始,对于任何支持的 DDL,默认算法是 INSTANT。这意味着 ALTER 语句只会修改数据字典中表的元数据。在操作的准备和执行阶段,不会对表进行独占元数据锁,表数据不受影响,使得操作是即时的。
另外两种算法是 COPY 和 INPLACE,Online DDL 操作参见手册。
然而,即使支持操作,Online DDL 也存在限制:一个表支持 64 次即时更改。到限制后,需要“重建”该表。
如果在 ALTER 语句(DDL 操作)期间未指定算法,则会默默地选择适当的算法。当然,如果没有预料到,这可能会导致生产中出现噩梦般的情况。
始终指定算法
因此,第一个建议始终是指定算法,即使它是执行 DDL 时的默认算法。当指定算法时,如果 MySQL 无法使用它,它将抛出错误,而不是使用其他算法执行操作:
SQL > ALTER TABLE t1 DROP col1, ALGORITHM=INSTANT; ERROR: 4092 (HY000): Maximum row versions reached for table test/t1. No more columns can be added or dropped instantly. Please use COPY/INPLACE.
监控即时变化
第二个建议也是监视对表执行的即时更改的数量。
MySQL 在 information_schema
表中保留行版本:
SQL > SELECT NAME, TOTAL_ROW_VERSIONS FROM INFORMATION_SCHEMA.INNODB_TABLES WHERE NAME LIKE 'test/t1'; +---------+--------------------+ | NAME | TOTAL_ROW_VERSIONS | +---------+--------------------+ | test/t1 | 63 | +---------+--------------------+
在上面的示例中,DBA 将能够执行一项额外的 INSTANT DDL 操作,但在此之后,MySQL 将无法执行另一项操作。
作为 DBA,监视所有表并决定何时需要重建表(以重置该计数器)是一个很好的做法。
这是添加到监控工具的建议查询的示例:
SQL > SELECT NAME, TOTAL_ROW_VERSIONS, 64-TOTAL_ROW_VERSIONS AS "REMAINING_INSTANT_DDLs", ROUND(TOTAL_ROW_VERSIONS/64 * 100,2) AS "DDLs %" FROM INFORMATION_SCHEMA.INNODB_TABLES WHERE TOTAL_ROW_VERSIONS > 0 ORDER BY 2 DESC; +--------------------------+--------------------+------------------------+--------+ | NAME | TOTAL_ROW_VERSIONS | REMAINING_INSTANT_DDLs | DDLs % | +--------------------------+--------------------+------------------------+--------+ | test/t1 | 63 | 1 | 98.44 | | test/t | 4 | 60 | 6.25 | | test2/t1 | 3 | 61 | 4.69 | | sbtest/sbtest1 | 2 | 62 | 3.13 | | test/deprecation_warning | 1 | 63 | 1.56 | +--------------------------+--------------------+------------------------+--------+
要重置计数器并重建表,可以使用 OPTIMIZE TABLE <table>
或 ALTER TABLE <table> ENGINE=InnoDB
结论
总之,MySQL 8.0 引入的 DDL 操作 INSTANT 算法通过避免阻塞更改彻底改变了模式更改。然而,由于 64 次即时更改的限制,在需要重建表之前,在 ALTER 语句期间显式指定算法以避免意外行为至关重要。还建议通过 information_schema
监视即时更改的数量,以避免在不知不觉中达到即时更改限制而出现意外情况,并仔细计划将表重建。
享受 MySQL!
更多技术文章,请访问:https://opensource.actionsky.com/
关于 SQLE
SQLE 是一款全方位的 SQL 质量管理平台,覆盖开发至生产环境的 SQL 审核和管理。支持主流的开源、商业、国产数据库,为开发和运维提供流程自动化能力,提升上线效率,提高数据质量。
SQLE 获取

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Compose Multiplatform 1.6.0:资源、UI 测试、iOS 辅助功能和预览注解 | Kotlin Blog
记得加关注, Kotlin 之路不迷路! Kotlinlang.org Compose Multiplatform 是由 JetBrains 开发的声明式 UI 框架,允许开发者跨平台共享 UI 实现。1.6.0 版本搭载多项强劲功能,同时与最新 Kotlin 版本以及 Google 最新 Jetpack Compose 更新¹中的更改兼容。 Compose Multiplatform 使用入门 https://www.jetbrains.com/help/kotlin-multiplatform-dev/compose-multiplatform-getting-started.html 这个版本的 Compose Multiplatform: 改进了资源管理库。 引入了 UI 测试 API。 添加了 iOS 辅助功能支持。 带来了许多功能和改进。 有关所显著更改的说明,请参阅我们的 Compose Multiplatform 1.6.0 最新变化²页面或 GitHub 上的版本说明³。 目录 通用资源 API 用于 UI 测试的通用 API iOS 辅助功能支持 Fleet 的...
- 下一篇
“不知今夕是何年”的周基年解法 | 得物技术
2024年1月5日,周五,本来是个美好的日子,期待着马上到来的周末。可是下午1点多,接到产品一个问题反馈,经过一番排查,23年7月份上线的功能,对于跨年场景的处理有问题,其核心在于“周的年”获取方式不正确。 举个🌰 (1)前端:页面按照周来选择,例如 2024-12-30,返回给后端的是 Year:2025 -Week:1。 2)后端:根据前端传递的 Year-Week 去DB中查询 数据开发回流的历史离线数据,神奇的事儿就发生了。如下图,数据中 Year字段,就不太正常,2024-12-30,应该是2025年的第一周。 同样的问题,也会出现在1月的开始几天,year字段不太正常。 这是出了什么问题呢? 因为不知今夕是何年啊!!! ISO-8601标准 ISO-8601是国际标准化组织(ISO)发布的日期和时间表示法的标准,它定义了一种统一的日期和时间格式。ISO-8601标准的目的是提供一种易于理解、易于比较和易于存储的日期和时间表示方法,以便在不同的计算机系统和地区之间进行交互和共享。 周的定义ISO-8601标准还定义了一种标准的周定义,用于表示周数。该定义基于一年中的周数,以...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS7,CentOS8安装Elasticsearch6.8.6
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- Hadoop3单机部署,实现最简伪集群
- CentOS8编译安装MySQL8.0.19
- CentOS8安装Docker,最新的服务器搭配容器使用
- Docker安装Oracle12C,快速搭建Oracle学习环境
- 设置Eclipse缩进为4个空格,增强代码规范
- MySQL8.0.19开启GTID主从同步CentOS8
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- CentOS6,CentOS7官方镜像安装Oracle11G