update sql docs

docs/basic/10.sql-Transaction.md

@@ -787,7 +787,12 @@ pt-osc 和 gh-ost 均采用拷表方式实现，即创建个空的新表，通
 
 不同之处在于处理 DDL 期间业务对表的 DML 操作（增删改）。
 
-在 8.0.29 之前的版本，仅支持在表最后一列即时添加列，不支持在表任一位置即时添加列
+
+从 `MySQL 8.0.28` 开始, InnoDB 支持 `ALTER TABLE ... RENAME COLUMN` 操作使用 `ALGORITHM=INSTANT`。
+
+从 `MySQL 8.0.29` 开始, InnoDB 支持 `ALTER TABLE ... DROP COLUMN` 操作使用 `ALGORITHM=INSTANT`。
+
+在 `8.0.29` 之前， instant 添加列，只能是加在表的最后一列，从 `8.0.29` 开始，可以在表的任意位置添加。
 
 在 8.0.29 之后，2 千万的表在任一位置即时添加列在秒级内完成。
 
@@ -797,7 +802,7 @@ ALTER TABLE sbtest1 ADD COLUMN k2 int(10) AFTER k,ALGORITHM=INSTANT;
 
 MySQL 8.0.29 开始，`ALTER TABLE … ALGORITHM=INSTANT` 支持删除某列。
 
-为了支持 `ALTER TABLE … ALGORITHM=INSTANT` 的新特性，InnoDB redo log 格式对于所有 DML 操作都发生了变化。
+为了支持 `ALTER TABLE … ALGORITHM=INSTANT` 的新特性，`InnoDB redo log` 格式对于所有 DML 操作都发生了变化。
 
 新的 redo 日志格式引入了一个设计缺陷，会导致 `instant add/drop columns` 的表数据损坏。
 
@@ -807,9 +812,9 @@ https://zhuanlan.zhihu.com/p/115277009
 
 ### MySQL 原子 DDL
 
-在 MySQL8.0 之前的版本中，这些元数据被存放在许多不同的文件中（.FRM，.PAR，.OPT，.TRN，.TRG 文件等），这就导致了一系列弊端，包括数据可能不一致、API 接口的复杂性等等，在之前的月报[5]中也有详细描述。元数据被放在许多不同的文件中，导致数据可能不一致的具体表现为：
+在 MySQL8.0 之前的版本中，这些元数据被存放在许多不同的文件中（.FRM，.PAR，.OPT，.TRN，.TRG 文件等），这就导致了一系列弊端，包括数据可能不一致、API 接口的复杂性等等，在之前的月报中也有详细描述。元数据被放在许多不同的文件中，导致数据可能不一致的具体表现为：
 
-- Server 层的 metadata 和 Storage Engine 层的 metadata 数据不一致
+- `Server` 层的 `metadata` 和 `Storage Engine` 层的 `metadata` 数据不一致
 
 - InnoDB 中的 metadata 和数据不一致
 
@@ -836,6 +841,8 @@ rename table t1 to t1_bak,t2 to t2_bak;
 
 什么是原子 DDL?
 
+
+
 当执行 DDL 时，数据字典更新、存储引擎操作和二进制日志中的写操作被合并到一个原子事务中，该事务要么完全执行，要么完全不执行。
 
 这提供了更好的可靠性，未完成的 ddl 不会留下任何不完整的数据。
@@ -872,6 +879,8 @@ ROLLBACK;
 
 ```
 
+https://www.cnblogs.com/radondb/p/16688994.html
+
 #### 支持的 DDL 语句
 
 原子 DDL 支持与表相关的 DDL 语句和与表无关的 DDL 语句。