爱可生 DBA 团队成员，会变身，主要负责 MySQL 故障处理和 SQL 审核优化。对技术执着，为客户负责。
大家好，本期讨论MySQL的DDL, 讨论的背景是MySQL 8.0+InnoDB。
昨天内容中说了MySQL5.6引入了online DDL，但是没有详细的展开说，这块儿内容比较多，只能一点一点的写了，今天再来看这里的内容。
MySQL 8.0.31于2022.10.11发布了，比我预计的日期早了一周，先赞一个。
导读：MySQL 的 DDL(Data Definition Language) 包括增减字段、增减索引等操作。在 MySQL 5.6 之前，MySQL 的 DDL 操作会按照原来的表复制一份，并做相应的修改。
我们码农平时大多数时间都在撸码或者撸码的路上，很少关注mysql的一些底层原理，当出现问题时没能力第一时间解决问题，出现问题后不去层层剖析问题产生的原因，后续也就可能无法避免或者绕开同类的问题。因此不要单纯做Ctrl+c和Ctrl+V，而是一边仰望星空(目标规划)，一边脚踏实地去分析每个问题。 在mysql系列专栏里面，我深入浅出的总结了mysql相关知识，感兴趣的话可以去阅读，有问题就可以随时相互交流学习。
POSTGRESQL 在 DDL DML DQL 都可以并行，之前MYSQL 在并行方面一直是软肋，MYSQL 8 已经提供了DQL的并行， DDL 的并行也支持了，从MYSQL5.X 升级到8 是必然了.
作者：徐文梁，爱可生 DBA 成员，一个执着于技术的数据库工程师，主要负责数据库日常运维工作。擅长 MySQL，Redis 及其他常见数据库也有涉猎；喜欢垂钓，看书，看风景，结交新朋友。
听到原子这个关键字大家是不是联想到事务的ACID的原子性？两者相似，事务/语句执行要么全部成功，要么全部失败。MySQL 8.0 之前的版本 DDL 是非原子性的，对于多条sql构成的ddl语句比如 rename table t1 to t1_bak,t2 to t2_bak; 执行过程中如果遇到系统异常crash，有可能出现表t1被rename，但是t2没有被rename的情况。出现该情况的原因就是MySQL不支持原子的DDL。
MySQL Online DDL 功能从 5.6 版本开始正式引入，发展到现在的 8.0 版本，经历了多次的调整和完善。本文主要就 Online DDL 的发展过程，以及各版本的区别进行总结。其实早在 MySQL 5.5 版本中就加入了 INPLACE DDL 方式，但是因为实现的问题，依然会阻塞 INSERT、UPDATE、DELETE 操作，这也是 MySQL 早期版本长期被吐槽的原因之一。
TiDB-DM（Data Migration）是用于将数据从 MySQL/MariaDB 迁移到 TiDB 的工具。该工具既支持以全量备份文件的方式将 MySQL/MariaDB 的数据导入到 TiDB，也支持通过解析执行 MySQL/MariaDB binlog 的方式将数据增量同步到 TiDB。特别地，对于有多个 MySQL/MariaDB 实例的分库分表需要合并后同步到同一个 TiDB 集群的场景，DM 提供了良好的支持。如果你需要从 MySQL/MariaDB 迁移到 TiDB，或者需要将 TiDB 作为 MySQL/MariaDB 的从库，DM 将是一个非常好的选择。
事情是这样子的，由于公司要推行降本增效，尽量使得服务器能满负载的去工作，我负责的项目由于对数据库的使用比较轻度，所以就降低配置去使用。而一个新的需求，需要稍微复杂一点的业务逻辑，所以需要对数据库增加一个字段，且增加一个索引，也就是做一点DDL语句的操作，但是由于表的数据量也不小(最大的一张表差不多800多万行，最少也有几百万条数据)，所以在此之前，对大表加字段，加索引做了一个比较深入的学习。
MySQL 8.0开始支持原子数据定义语言（DDL）语句。此功能称为原子DDL。原子DDL语句将与DDL操作关联的数据字典更新，存储引擎操作和二进制日志写入组合到单个原子事务中。即使服务器在操作期间暂停，也会提交事务，并将适用的更改保留到数据字典，存储引擎和二进制日志，或者回滚事务。
Roy，携程软件技术专家，负责MySQL双向同步DRC和数据库访问中间件DAL的开发演进，对分布式系统高可用设计、数据一致性领域感兴趣。
日常开发我们对一条DML语句较为熟悉，很多开发人员都了解sql的执行过程，比较熟悉，但是DDL是如何执行的呢，大部分开发人员可能不太关心，也认为没必要了解，都交给DBA吧。其实不然，了解一些能尽量避开一些ddl的坑，那么下面带大家一起了解一下DDL执行的方式，也算抛砖引玉吧。如有错误，还请各位大佬们指正。
上周一篇关于MySQL 拜托加个索引能和PG一样简单吗？只能gh-ost了 烦人，的帖子引起争议，主要因为我提到 POSTGRESQL 在线添加索引是非常方便的，MySQL 在这方面不咋地，首先说结果，我对MYSQL的知识需要更新，针对高版本得MYSQL是支持online ddl index，所以写这篇来纠正一下，但是有一些同学发了一些MYSQL 支持online ddl index 的绝对论甚至有人说mysql 5.x就可以onine ddl index，这点咱们也的纠正，对就是对，错就是错。
在MySQL5.7中，所有的临时表都被创建在一个叫“ibtmp1”的表空间中。另外，临时表的元数据也将存储在内存中（不再存储在frm文件中）。
MySQL 中在运行一个 DDL , 此时我们对这个 DDL 进行 kill , 那这个 DDL 多久会被 kill 掉? 要讨论这个问题, 我们需要拆分问题: DDL 多久会被 kill 掉 = D
很早就听说 MySQL8.0 支持快速加列，可以实现大表秒级加字段。笔者自己本地也有8.0环境，但一直未进行测试。本篇文章我们就一起来看下 MySQL8.0 快速加列到底要如何操作。
MySQL8.0支持原子DDL。原子DDL将DDL操作相关联的数据字典更新、存储引擎操作和二进制日志写入合并到单个原子事务中。
DDL 一向是业务的痛点，尤其是对大型表的 DDL 操作，具有操作时间久，对性能影响大，可能影响业务正常使用等问题。
数据库的集群架构都不陌生了，最熟悉也是应用最广泛的就是咱们熟知的主从，今天大概的回味下： 主从复制 MySQL复制基于主服务器在二进制日志中跟踪所有对数据库的更改(更新、删除等等)。因此，要进行复制，
Mysql为了解决这个风险并提高复制的性能，将Slave端的复制改为两个进程来完成。提出这个改进方案的人是Yahoo!的一位工程师“Jeremy Zawodny”。这样既解决了性能问题，又缩短了异步的延时时间，同时也减少了可能存在的数据丢失量。当然，即使是换成了现在这样两个线程处理以后，同样也还是存在slave数据延时以及数据丢失的可能性的，毕竟这个复制是异步的。只要数据的更改不是在一个事物中，这些问题都是会存在的。如果要完全避免这些问题，就只能用mysql的cluster来解决了。不过mysql的cluster是内存数据库的解决方案，需要将所有数据都load到内存中，这样就对内存的要求就非常大了，对于一般的应用来说可实施性不是太大。
MySQL 8.0.27引入了一个新变量“innodb_ddl_threads”，用来控制 InnoDB 创建（排序和构建）二级索引的最大并行线程数。
数据库锁设计的初衷是处理并发问题。作为多用户共享的资源，当出现并发访问的时候，数据库需要合理地控制资源的访问规则。而锁就是用来实现这些访问规则的重要数据结构。
好几年没写技术博客了，今天写一个小的技术点给大家分享，关于MySQL JDBC StreamResult的原理分享，难度不大，就当程序员的闲聊。
MySQL 8.0 将数据库元信息都存放于InnoDB存储引擎表中，在之前版本的MySQL中，数据字典不仅仅存放于特定的存储引擎表中，还存放于元数据文件、非事务性存储引擎表中。本文将会介绍MySQL 8.0对数据字典的改进，以及改进带来的好处、影响以及局限性。
Innodb早期支持通过copy table跟inplace的方式来执行DDL语句，其原理如下：
错误提示是主键冲突，但是当我们去查询 id= 7458421 时，并无此记录。是不是很奇怪？遇到这种情况，一般有如下场景:
今天对线上某个业务的大表120G进行重建表操作时遇到报错，该表有个比较显著的特征是*写入量比较大，每天写入加更新的频率在数千万级别。大致的环境
今天主要介绍一下MySQL 8.0.19 instant add column的新特性，基于亿级数据秒速增加字段，下面一起来看看吧~
一大早收到一封oracle官方发来的邮件，邀请我参加mysql改版的网路研讨会。作为一个后端开发者，想必对mysql是非常是熟悉了。下面来聊一聊mysql8.0的新特性。 临时表的改进 在MySQL5.7中，所有的临时表都被创建在一个叫“ibtmp1”的表空间中。另外，临时表的元数据也将存储在内存中（不再存储在frm文件中）。 在MySQL8.0中，使用临时表存储引擎作为临时表（为优化JOIN、UNION等操作而创建的）存储的默认引擎，从而替换掉了原有的内存存储引擎。 新的引擎使得VARCHAR和VARBI
单主模式：只有一个成员对外提供服务。单主模式和异步模式比较类似，有了主从复制的经验，维护单主模式的MGR其实并不难，下面的图说明了单主模式下的一些特点：
有时候需要审计看看谁执行了啥操作. 但很多环境是没得审计的. 这时候就可以通过解析binlog 得到ddl执行的记录了(审计dml套麻烦了).
经常会有同学来问我，我的数据库占用空间太大，我把一个最大的表删掉了一半的数据，怎么表文件的大小还是没变？
本节描述了如何安装或卸载ddl_rewriter插件。有关安装插件的一般信息，请参见 Section 7.6.1，“安装和卸载插件”。
其他关于C3P0的详细内容, 可参考C3P0主页. HikariCP HikariCP是另一款高性能/”零开销”/高品质的数据库连接池,据测试,其性能优于C3P0(详细信息可参考号称性能最好的JDBC连接池:HikariCP),但国内HikariCP资料不多,其项目主页为https://github.com/brettwooldridge/HikariCP,使用HikariCP需要在pom.xml中添加如下依赖: <dependency> <groupId>com.zaxxer</groupId>
MySQL里面对于表的默认的配置是每个表都有独立的文件.ibd和.frm文件对应，对于数据恢复来说，会提供很大的便利。
如果主从复制之间出现延时，就会影响主从数据的一致性。 此时发生容灾切换，且在新的主库写入了数据，那么从业务角度上，会产生意想不到的严重后果。 复制延时问题，在只读从库的场景下，若从库产生复制延时，也可能会对业务造成一定影响，比如在业务上表现为读写不一致——新增/修改数据查不到等现象。 由此可见，主从复制的延时问题在数据库运营中需要特别关注。一般来说，DBA在库上执行SHOW SLAVE STATUS，并且观察 Seconds_Behind_Master的值，就能够了解当前某个数据库和它的主库之间的数据复制延时。
背景 MySQL 8.0 DDL 是一个复杂的过程，涉及比较多的模块，例如：MDL 锁，表定义缓存，行格式，Row Log，DDL Log，online 属性，表空间物理文件操作等。本文主要通过与5.
前面一篇文章介绍了 MySQL clone plugin 实践操作 。本文继续深入学习 clone 插件的 相关技术知识。
MySQL的主从复制都是单线程的操作，主库对所有DDL和DML产生的日志写进binlog，由于binlog是顺序写，所以效率很高。 Slave的SQL Thread线程将主库的DDL和DML操作事件在slave中重放。DML和DDL的IO操作是随即的，不是顺序的，成本高很多。 另一方面，由于SQL Thread也是单线程的，当主库的并发较高时，产生的DML数量超过slave的SQL Thread所能处理的速度，或者当slave中有大型query语句产生了锁等待那么延时就产生了。 常见原因：Master负载过高、Slave负载过高、网络延迟、机器性能太低、MySQL配置不合理。
日志的存在，为数据库的很多功能提供了保障。像用于回滚数据的 undo log，用于恢复数据的 redo log， 以及用于主从备份的 binlog。本文将会大致介绍下数据库里的日志类别，以及重点分析下事务日志的相关知识点。
在《0基础学习PyFlink——使用PyFlink的Sink将结果输出到外部系统》一文中，我们将字数统计结果输出到终端。本文将模拟生产环境，将结果输出到Mysql数据库。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
腾讯会议
实时音视频
