MySQLDDL为什么成本高？中，我们介绍了：传统情况下，为表添加列需要对表进行重建腾讯团队为MySQL引入了InstantAddColumn的方案（以下称为立刻加列功能）可以快速完成为表添加列的任务同时我们留了以下思考题：立刻加列是如何工作的?所谓立刻加列是否完全不影响业务，是否是真正的立刻完成?本期我们针对这几个问题来进行讨论：传统情况我们先回顾一下，在没有立刻加列功能时，加列操作是怎么完成的。我们也借此来熟悉一下本期的图例：当进行加列操作时，所有的数据行都必须要增加一段数据（图中的列4数据）如上一期图解所讲，当改变数据行的长度，就需要重建表空间（图中灰蓝的部分为发生变更的部分）数据字典中的列定义也会被更新以上操作的问题在于每次加列操作都需要重建表空间，这就需要大量IO以及大量的时间立刻加列立刻加列的过程如下图：立刻加列时，只会变更数据字典中的内容，包括：在列定义中增加新列的定义增加新列的默认值立刻加列后，当要读取表中的数据时：由于立刻加列没有变更行数据，读取的行数据只有3列MySQL会将新增的第4列的默认值，追加到读取的数据后以上过程描述了如何读取在立刻加列之前写入的数据，其实质是：在读取数据的过程中，伪造了一个新列出来那么如何读取在立刻加列之后写入的数据呢?过程如下图：当读取行4时：通过判断数据行的头信息中的instant标志位，可以知道该行的格式是新格式：该行头信息后有一个新字段列数通过读取数据行的列数字段，可以知道该行数据中多少列有真实的数据，从而按列数读取数据通过上图可以看到：读取在立刻加列前/后写入的数据是不同的流程通过以上的讨论，我们可以总结立刻加列之所以高效的原因是：在执行立刻加列时，不变更数据行的结构读取旧数据时，伪造新增的列，使结果正确写入新数据时，使用了新的数据格式（增加了instant标志位和列数字段)，以区分新旧数据读取新数据时，可以如实读取数据那么我们是否能一直伪造下去?伪造何时会被拆穿?考虑以下场景：用立刻加列增加列A写入数据行1用立刻加列增加列B写入数据行2删除列B我们推测一下删除列B的最小代价：需要修改数据行中的instant标志位或列数字段，这至少会影响到立刻加列之后写入的数据行，成本类似于重建数据从以上推测可知：当出现与立刻加列操作不兼容的DDL操作时，数据表需要进行重建，如下图所示：扩展思考题：是否能设计其他的数据格式，取代instant标志位和列数字段，使得加列/删列操作都能立刻完成?（提示：考虑加列-删列-再加列的情况）使用限制在了解原理之后，我们来看看立刻加列的使用限制，就很容易能理解其中的前两项：立刻加列的加列位置只能在表的最后，而不能加在其他列之间在元数据中，只记录了数据行应有多少列，而没有记录这些列应出现的位置。所以无法实现指定列的位置立刻加列不能添加主键列加列不能涉及聚簇索引的变更，否则就变成了重建操作，不是立刻完成了立刻加列不支持压缩的表格式按照WL的说法：COMPRESSEDisnoneedtosupported（没必要支持不怎么用的格式）总结回顾我们总结一下上面的讨论：立刻加列之所以高效的原因是：在执行立刻加列时，不变更数据行的结构读取旧数据时，伪造新增的列，使结果正确写入新数据时，使用了新的数据格式(增加了instant标志位和列数字段)，以区分新旧数据读取新数据时，可以如实读取数据立刻加列的伪造手法，不能一直维持下去。当发生与立刻加列操作不兼容的DDL时，表数据就会发生重建回到之前遗留的两个问题：立刻加列是如何工作的?我们已经解答了这个问题所谓立刻加列是否完全不影响业务，是否是真正的立刻完成?可以看到：就算是立刻加列，也需要变更数据字典，那么该上的锁还是逃不掉的。也就是说这里的立刻指的是不变更数据行的结构，而并非指零成本地完成任务