ALGORITHM=INSTANT：加列为什么可以不重建整张表

做的事：200万行的表，做两种不同的ALTER

一种是加列，一种是改列的数据类型。

操作插入200万行到t9 ALTER TABLE t9 ADD COLUMN new_col VARCHAR(50), ALGORITHM=INSTANT ALTER TABLE t9 MODIFY COLUMN v BIGINT, ALGORITHM=INPLACE -- 先试试这个

验证：加列，200万行的表只要6.6毫秒

不管表多大，INSTANT算法都不用碰已有数据。

结果ALGORITHM=INSTANT 耗时: 0.0066 s

200万行的表，加一列只要6.6毫秒——这个耗时基本不会随着表的行数增长，因为INSTANT算法压根不去碰任何一行已有数据，只是往表的元数据（数据字典）里记录"这张表现在多了一列，新行要按新结构存，老行读取时缺的字段就当作默认值处理"。

验证：改数据类型，连INPLACE都不支持

不是所有DDL都能走轻量算法。

结果ALTER TABLE t9 MODIFY COLUMN v BIGINT, ALGORITHM=INPLACE → 报错: ALGORITHM=INPLACE is not supported. Reason: Cannot change column type INPLACE. Try ALGORITHM=COPY.

改变一列的数据类型（这里是INT改BIGINT），意味着这一列已有的每一行数据都要按新类型重新编码存储——这已经不是"改改元数据"能解决的，MySQL直接拒绝了INPLACE，只给出COPY这一条路。

验证：ALGORITHM=COPY，要重建整张表

同样200万行，走COPY算法耗时多少。

结果ALTER TABLE t9 MODIFY COLUMN v BIGINT, ALGORITHM=COPY 耗时: 3.0938 s （数据完整性验证：SELECT COUNT(*) FROM t9 → 2000000，一行没少）

3.0938秒，跟INSTANT的0.0066秒相比，慢了约469倍。COPY算法做的事情是：创建一张带新结构的临时表，把老表200万行数据逐行读出来、按新类型转换、写进临时表，最后再原子性地把临时表切换成正式表——这才是的"重建整张表"，耗时随行数线性增长，行数越多这个代价越可怕。

分步演示：三种DDL算法的耗时差距

每一步都是本文上面在200万行表上跑出来的原始耗时。