tidb：v5.2.1
有张大表进行 修改字段类型的ddl操作，报错：Transaction is too large, size: 105034020
有两个问题：
1.按该文章描述，修改字段类型应该是跟数据量无关的，单实际是 表越大，更新越慢，且报如上错误
2.ddl语句为啥会有dml语句的事务限制？
1 个赞
上面这篇关于 DDL 的描述适用于 3.0 版本，有限支持 column 类型的情况，如果是 v5.2 版本，对 column 类型的 modify 兼容更多。如果方便辛苦提供下面的信息：
- DDL 修改 column 类型完整的语句
- DDL owner 在 modify column 类型 sql 执行期间对应的 tidb.log 信息
- select version() 确认下版本信息
1 个赞
- ALTER TABLE kol.kol_doc MODIFY COLUMN engagement_update_time DATETIME;
是将timestamp转为datetime(因为tidb时区问题流入下游少8小时，我们准备将timestamp改为datetime，再修改时区，保证时间不变)
2.日志如下：
tidb.tar.gz (3.2 MB)
3.版本如下：
4.修改txn-total-size-limit，扩大到4G，并无作用，ddl 的Transaction不是用的dml的事务参数
1 个赞
-
找到集群中的 DDL owner 节点，在每个 tidb server 上，使用 tidb_is_ddl_owner 找到 DDL owner
https://docs.pingcap.com/zh/tidb/stable/tidb-functions#tidb_is_ddl_owner
-
到 DDL owner 的 tidb server 节点中，找到执行更改列类型时间段的日志，并上传到帖子中
-
提供下下述参数的设置：
https://docs.pingcap.com/zh/tidb/stable/system-variables#tidb_ddl_reorg_batch_size
https://docs.pingcap.com/zh/tidb/stable/system-variables#tidb_ddl_reorg_worker_cnt
1 个赞
这里面的日志最早的时间是 06:34 分钟，看到你上面的 admin show ddl jobs 的时间并不能包括在这个日志文件内
建议这样取下日志：
-
admin show ddl jobs 看下
ALTER TABLE kol.kol_doc MODIFY COLUMN engagement_update_time DATETIME;语句对应的完整的信息（之前截图的信息不完整），包括 job id，start time，end time -
找到 alter 语句对应的 ddl 详细的信息后，根据 job id 以及 start_time 到 ddl owner 的 tidb server 上找到对应的 log 并上传
-
也可以使用 tidb api 再次确认下集群中的 ddl owner 节点
以上，辛苦~
1 个赞
收到，这边先看下，有进展会在跟帖回复 ~
1 个赞
好的，请您尽快确认和回复下啊，感谢
1 个赞
造成这个问题的原因是，在 reorg 的过程中，DDL 的 batch size(1024) * table line size 的大小超过了事务大小限制。所以你那里可以尝试通过下面的方式来缓解这个报错，建议优先选择方式 1：
-
方式 1：调整 batch size 为 1024 → 256
-
方式 2：调整大事务限制参数
1 个赞
使用方式一，目前已经在跑了，半个小时跑了500w左右，按照上面文章说的，modify column预估耗时1秒左右，应该是跟数据量无关的，但目前来看跟数据量有很大关系，这个可以调大tidb_ddl_reorg_worker_cnt来增加 ddl处理速度吗，还有没有别的参数来加快
1 个赞
上面的文章是 3.0 版本，3.0 版本 modify column 因为有限支持，比如 varchar(10) → varchar(20), 所以是通过修改元数据完成的，速度非常快。现在你那里的环境是 5.2 版本，支持的修改类型增加了，比如 timestamp → datetime 那么需要经历 reorg 过程，数据重新回填，这个过程参考 add index 流程 ~
如果想要加速，那么可以使用第二种方式，调大事务限制参数观察下，但是需要注意调大事务限制的注意事项 ~
1 个赞
感觉上事务限制的参数不会加快处理吧。。。worker_cnt可以吗，另外5.2.1可以一次修改多个字段类型吗，行存，都要读整行数据，是否可以一次都改了
1 个赞
好像越跑越慢了，最开始半小时能跑500w数据，现在4个小时了才跑了2000w。。
回填数据的操作类似一个写入操作，读+写。
如果想要提速，那么可以考虑
- 方式 1：调大 worker count 参数
- 方式 2： batch size + 大事务参数（避免再次出现 Transaction is too large, size: 105034020）
但是这样的话，对线上的业务影响会比较大，建议评估后操作。相关文档见：
1 个赞
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。