适配tidb问题，DDL语句执行时间过长导致应用发布超时问题

[TiDBer_sUGm8DSa]

有没有大佬可以解答下tidb这个DDL语句性能问题，在一台4c8g的mysql数据库上修改表字段数据类型基本上都是毫秒级，tidb上评估3秒。

【 TiDB 使用环境】测试
【 TiDB 版本】v6.1.0
【复现路径】直接使用数据库连接工具BEAVER测试数据库修改表字段数据类型，执行时长平均3s.
执行语句示例：
ALTER TABLE XD_wbshe59p_V20221118173739.Smt_AppEnviroment MODIFY COLUMN EnviromentName varchar(250) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL;
执行结果截图：

【遇到的问题：问题现象及影响】
影响应用发布，数据库语句执行时间过长，导致应用打包超时。
【资源配置】
tidb-pd 4c8g
TiKV-01 4c8g
TiKV-02 4c8g
TiKV-03 4c8g
TiCDC 4c8g
TiFlash 8c16g
【附件：截图/日志/监控】

[h5n1]

tidb有个特性为了保证async commit的一致性，类似加二级索引这种ddl会等2秒

[TiDBer_sUGm8DSa]

大佬有没有办法解决这种DDL语句运行时间过长问题？

[我是咖啡哥]

• 由于和 Async Commit 功能兼容，DDL 在开始进入到 Reorg Data 前会有一定时间（约 2.5s）的等待处理：

Query OK, 0 rows affected (2.52 sec)

https://docs.pingcap.com/zh/tidb/stable/sql-statement-modify-column#reorg-data-change

文档上确实有说明。get了 感谢@h5n1 大佬

[特雷西-迈克-格雷迪]

我的实例就没有等待，版本6.1.2

[buddyyuan]

admin show ddl jobs;
查一下结果。

[TiDBer_sUGm8DSa]

我升级到6.4.0还是有这个问题

[TiDBer_sUGm8DSa]

[buddyyuan]

把这一堆脚本拿到 mysql 客户端下跑下看看，你改这个字段是改大还是改小？

[TiDBer_sUGm8DSa]

在mysql下改大改小都是毫秒级的

[buddyyuan]

既然在MySQL客户端下没问题，那就是DBeaver客户端的问题了。

[TiDBer_sUGm8DSa]

我用的同一个客户端都是DBEAVER，对应的数据库不同，一个是tidb，另一个是mysql。就tidb有这个问题。

[Aric (Jansu Dev)]

1. 首先，无法确保 DBEAVER 没有问题，碰到过好几次 navicat, DBEAVER 和 mysql client 行为有差的情况，而且 MySQL 和 TiDB 后面采用不同的实现🤔，只是兼容了 MySQL Protocol，大概率是三方工具的问题；
2. 其次，说回问题，测试环境吧慢日志阈值置为 0 采集所有 SQL，抓到这个 DDL，然后看下里面的信息有没有用，慢在哪个阶段了（只是一个思路，不一定能最终解掉这个问题，可能有用）。