【TiDBer 唠嗑茶话会 141】关于 TiDB DDL 你有哪些使用反馈和建议！参与评论即可获 100 积分奖励 & 抽 5 位参与调研的小伙伴送 TiDB 社区最新款金属手机支架和新款皮质收纳袋！

像风一样的男子 · 2024 年11 月 4 日 05:29

1 当前TiDB 版本：v6.5.10
2 执行 DDL 时，还遇到哪些痛点？暂无
3 建议TIDB尽快支持存储过程

Hacker007 · 2024 年11 月 4 日 06:21

v5.4,v6.5
2.没有使用过
目前tidb相当于是mysql的从库，ddl很少

Holland · 2024 年11 月 4 日 06:32

当前使用的 TiDB 版本：v7.5.1
使用过 tidb_ddl_enable_fast_reorg 来加速索引的创建
1.6亿的表，使用前加索引超过1小时，使用后3分钟。
当前您在执行 DDL 时，还遇到哪些痛点？ddl卡死并且阻塞后面的ddl
还有哪些 DDL 功能是您迫切希望支持的？暂无
其他反馈和建议无

tidb菜鸟一只 · 2024 年11 月 4 日 07:26

当前使用的 TiDB 版本：
6.5.10
是否有使用过 tidb_ddl_enable_fast_reorg（v6.5默认开启），tidb_enable_dist_task（v8.1默认开启）来加速索引的创建？
tidb_ddl_enable_fast_reorg用过，tidb_enable_dist_task还没用
如果有，最大的一个表有多少数据量？该表有多行？多少列？
最大的表420G,该表10亿行，8列
使用这些特性前后，加索引的耗时分别是多少？
使用tidb_ddl_enable_fast_reorg前，建索引耗时3个小时，使用之后建索引耗时1个小时
tidb_ddl_reorg_batch_size 和 tidb_ddl_reorg_worker_cnt 在 v8.3 版本的行为变更影响是否可接受？
这 2 个变量，调大时，会提升 DDL 性能，但是相应的也会消耗更多的集群资源。在 v8.3 之前仅支持 Global 级别设置，因此需要 SUPER 或者 SYSTEM_VARIABLES_ADMIN 权限才能修改。如果公司权限分的比较细，修改这 2 个变量，需要提交工单给具有相应权限的人，让他们来修改。因此当加索引频率较高，同时为了避免对业务影响，不同时间需要设置不同的值时。这个权限限制，使得加索引不够灵活。
因此从 v8.3 开始支持了 session 级别设置该参数，无需 SUPER 或者 SYSTEM_VARIABLES_ADMIN 权限。但是会导致在 Global 级别设置这 2 个参数取值，不再对运行中的 Add index , Modify column , reorgnize partition 这 3 类 DDL 任务生效。需要 Cancel 这些 DDL job，重新提交。对于这个变动的影响，是否可接受？
对于该变更，你有哪些看法和建议？
我觉得session级别调整参数可以接受，但是权限还是应该保持高一点，因为这个参数调整过高会对整个集群造成影响。
当前您在执行 DDL 时，还遇到哪些痛点？请结合应用场景举例说明。
增加虚拟列，由于列中没有对应的json key导致报错，导致卡住不动，必须手工杀死进程。
还有哪些 DDL 功能是您迫切希望支持的？
自动回退ddl操作，有些操作执行错误会一直卡着
使用快速加索引功能过程中对于你们在线业务的影响这方面体验如何？
很好
其他反馈和建议。
无

随便改个用户名 · 2024 年11 月 4 日 08:52

当前使用的 TiDB 版本：v6.5.6
当前您在执行 DDL 时，还遇到哪些痛点？暂无
还有哪些 DDL 功能是您迫切希望支持的？暂无

没头脑123 · 2024 年11 月 4 日 09:21

1、当前使用的 TiDB 版本：v7.5
2、暂无
3、暂无
4、当前您在执行 DDL 时，还遇到哪些痛点？请结合应用场景举例说明。
超大表加索引非常慢，耗时超过1天+。非常恐怖。
5、还有哪些 DDL 功能是您迫切希望支持的？
多场景下的在线ddl，超大表加索引要超快
6、影响较小，一般不加，提前设计。
7、其他反馈和建议。
DDL 还是需要更丝滑，影响更小

TiDBer_21wZg5fm · 2024 年11 月 4 日 10:47

最近没更新

TiDBer_jYQINSnf · 2024 年11 月 4 日 11:36

1、当前使用的TiDB版本为：5.4
2、当前您在使用DDL时，还遇到哪些痛点？DDL 不同表的 DDL 不能并行处理，
3、还有哪些DDL功能是您迫切希望支持的？如果上述需求在新版本支持了，就没什么需求了，很好。
4、其他反馈和建议：已经很优秀了

kelvin · 2024 年11 月 4 日 11:53

1 当前TiDB 版本：v6.5
2 执行 DDL 时，还遇到哪些痛点？目前暂无
如果能支持存储过程就更好

迷途小书童 · 2024 年11 月 5 日 00:30

当前使用的 TiDB 版本：v7.5.3；
暂无；
接受， DDL 任务的执行频率低，暂无建议；
痛点：对于高并发写入的业务，DDL 操作可能会引起较长时间的锁等待或阻塞，尤其是当表数据量非常大的时候；
在线索引创建、并行化 DDL 任务、增加灵活性：支持 session 级别的设置对于调整加速参数非常有帮助，尤其是在负载较高时，根据具体需求动态调整；
暂无；
希望社区版也能支持存储过程。

TiDBer_刚 · 2024 年11 月 5 日 00:58

1、当前使用的 TiDB 版本：v7.5
2、否
3、未使用
4、当前您在执行 DDL 时，还遇到哪些痛点？请结合应用场景举例说明。
在业务量大的情况下执行DDL可能会影响业务
5、还有哪些 DDL 功能是您迫切希望支持的？
online DDL的增强
7、其他反馈和建议。
希望真正实现在线DDL时无感。

Jellybean · 2024 年11 月 5 日 01:09

当前使用的 TiDB 版本：

v7.1.x

是否有使用过 tidb_ddl_enable_fast_reorg（v6.5默认开启），tidb_enable_dist_task（v8.1默认开启）来加速索引的创建？

测试环境有使用过。
生产环境未使用过，一直使用的默认值。

tidb_ddl_reorg_batch_size 和 tidb_ddl_reorg_worker_cnt 在 v8.3 版本的行为变更影响是否可接受？

由于调整DDL会消耗集群更多资源，建议通过严格控制权限来避免滥用。需要 SUPER 或者 SYSTEM_VARIABLES_ADMIN 权限才能修改。不建议支持了 session 级别设置该参数，反而可以通过授权的方式指定某些用户可以修改，而不是一刀切都支持 session 级别设置该参数。

当前您在执行 DDL 时，还遇到哪些痛点？请结合应用场景举例说明。

对大表DDL执行进度的可视化监控。
DDL被阻塞或者阻塞其他任务的可视化情况，以及告警。

还有哪些 DDL 功能是您迫切希望支持的？

完善DDL的可视化监控和告警。

使用快速加索引功能过程中对于你们在线业务的影响这方面体验如何？

v6.5开启后，对一个40亿行的大表添加索引，速度提升为原来的10倍！！体验当然非常好！

其他反馈和建议。

完善DDL执行任务时的资源消耗，尽可能做到平滑操作，集群几乎无感知
提升DDL任务的稳定性

opkcloud · 2024 年11 月 5 日 01:31

当前使用的 TiDB 版本：
V7.5.4
是否有使用过 tidb_ddl_enable_fast_reorg（v6.5默认开启），tidb_enable_dist_task（v8.1默认开启）来加速索引的创建？
暂无
tidb_ddl_reorg_batch_size 和 tidb_ddl_reorg_worker_cnt 在 v8.3 版本的行为变更影响是否可接受？
可接受
当前您在执行 DDL 时，还遇到哪些痛点？请结合应用场景举例说明。
执行等待问题
还有哪些 DDL 功能是您迫切希望支持的？
官方目前支持的在使用，暂无很好的想法
使用快速加索引功能过程中对于你们在线业务的影响这方面体验如何？
加索引时间花费更少，对业务没有影响
其他反馈和建议。继续关注

TiDBer_徐川 · 2024 年11 月 5 日 03:02

1、当前使用的 TiDB 版本是 v7.x。

2、有使用过 tidb_ddl_enable_fast_reorg 和 tidb_enable_dist_task 来加速索引的创建。最大的一个表数据量约为 1TB，该表有大约 5000 万行，50 列。使用这些特性前，加索引耗时约为 5 小时；使用后，耗时约为 2 小时。

3、tidb_ddl_reorg_batch_size 和 tidb_ddl_reorg_worker_cnt 在 v8.3 版本的行为变更影响基本可接受。这个变更使得在不同场景下调整参数更加灵活，无需频繁提交工单等待有权限的人来修改参数，大大提高了工作效率。不过，需要注意的是，在使用 session 级别设置参数时，要确保对正在运行的 DDL 任务有清晰的了解，以免出现意外情况。建议在文档中更加详细地说明如何在不同场景下合理设置这两个参数，以及可能出现的风险和应对措施。

4、当前在执行 DDL 时，一个痛点是在大规模数据量的表上进行复杂的 DDL 操作时，仍然会对业务产生一定的影响。例如，在对一个包含大量历史数据的表进行结构调整时，即使使用了加速特性，也会导致业务查询响应时间变长，影响用户体验。

5、希望 TiDB 能够支持更加智能的 DDL 规划，例如根据业务负载自动选择最佳的时间进行 DDL 操作，以最大程度地减少对业务的影响。

6、使用快速加索引功能对在线业务的影响总体来说比较小。在加索引过程中，业务查询和写入的性能有一定的下降，但在可接受范围内。而且加索引的速度提升明显，减少了业务受影响的时间。

7、建议 TiDB 团队在未来的版本中继续优化 DDL 性能，提供更多的参数调整选项，以满足不同业务场景的需求。同时，加强对 DDL 操作的监控和管理，提供更加详细的日志和指标，以便开发者更好地了解 DDL 操作的进展和影响。

ZhaoQi99 · 2024 年11 月 5 日 03:12

当前使用的 TiDB 版本：v8.2
没有使用过 tidb_ddl_enable_fast_reorg 和tidb_enable_dist_task
可接受
回滚？
自定选择合适时间执行
时间更短
暂无其他反馈和建议，社区做的很棒

TiDBer_dog · 2024 年11 月 5 日 03:26

1、当前使用的 TiDB 版本是 v7.1。
2、使用过 tidb_ddl_enable_fast_reorg 和 tidb_enable_dist_task 来加速索引的创建。最大的一个表数据量约为 800GB，该表有大约 4500 万行，45 列。使用这些特性前，加索引耗时约为 6 小时；使用后，耗时约为 2.5 小时。
3、tidb_ddl_reorg_batch_size 和 tidb_ddl_reorg_worker_cnt 在 v8.3 版本的行为变更有一定影响，但可以接受。变更后在不同场景下调整参数更加方便，但需要注意对资源的合理分配。建议提供一些参数调整的最佳实践，帮助用户更好地平衡性能和资源消耗。
4、执行 DDL 时的痛点在于，对于大型表的 DDL 操作，即使使用了加速特性，也会占用大量的磁盘空间和网络资源，影响其他业务的运行。例如在进行大规模数据迁移时，网络带宽被大量占用，导致其他业务的响应时间变长。
5、希望 DDL 功能能够支持更高效的数据迁移工具，减少迁移过程中的资源占用和时间消耗。
6、使用快速加索引功能对在线业务有一定影响，主要体现在加索引期间业务的写入速度有所降低，但查询性能基本不受影响。
7、可以考虑增加对 DDL 操作的进度监控和可视化功能，让用户更直观地了解操作的进展情况。

zhimadi · 2024 年11 月 5 日 06:15

1、当前使用的 TiDB 版本：v5.4.2
2、否
4、当前您在执行 DDL 时，还遇到一、大表加索引耗时久；二、IO持续飙升。
5、还有哪些 DDL 功能是您迫切希望支持的？增加存储过程和函数

MrSylar · 2024 年11 月 5 日 06:30

1.v5.1、v5.3、v6.5、v6.5

2.v6.5 引入的 tidb_ddl_enable_fast_reorg 大多数情况能加速索引的创建，但个别情况下也能无效、甚至可能更慢

3.灵活性与稳定性的取舍，从我企业的角度看反对该变更。稳定性是首要需求。从个人角度看，建议是否可以做一个开关，业务需求不同时，通过开关控制是否允许 session 级修改。

4.痛点1）如果 ddl 出问题，比如hang住，排错方式和手段目前不够优秀

痛点2）tidb_ddl_reorg_batch_size 和 tidb_ddl_reorg_worker_cnt 可以加速ddl的执行，但是效果不是可预期的，只能试

5.取消DDL的各种限制，比如分区表不支持数据类型的变更

6.v6.5 版本 tidb_ddl_enable_fast_reorg 表现不是很好，所以默认关闭了。

danghuagood · 2024 年11 月 5 日 06:53

当前使用的 TiDB 版本：
V6.5.1
是否有使用过 tidb_ddl_enable_fast_reorg（v6.5默认开启），tidb_enable_dist_task（v8.1默认开启）来加速索引的创建？
是

如果有，最大的一个表有多少数据量？该表有多行？多少列？
使用这些特性前后，加索引的耗时分别是多少？
30亿数据量，117列
没有对比过，开完以后整个耗时在3小时左右

tidb_ddl_reorg_batch_size 和 tidb_ddl_reorg_worker_cnt 在 v8.3 版本的行为变更影响是否可接受？

感觉还可以接受

当前您在执行 DDL 时，还遇到哪些痛点？请结合应用场景举例说明。
磁盘预估不准确，修改过程中无法感知进展
还有哪些 DDL 功能是您迫切希望支持的？
暂无
使用快速加索引功能过程中对于你们在线业务的影响这方面体验如何？
收益还是比较明显，原来需要通宵熬夜搞，现在不用通宿搞
其他反馈和建议。
暂无

dba-kit · 2024 年11 月 5 日 08:56

当前使用的 TiDB 版本：7.5.4
是否有使用过 tidb_ddl_enable_fast_reorg：已经使用该功能，加索引速度至少提升10倍。
tidb_ddl_reorg_batch_size 和 tidb_ddl_reorg_worker_cnt 在 v8.3 版本的行为变更影响是否可接受？
我感觉反而没有必要增加 Session 级别的变量，我个人使用的场景，是根据集群实际资源使用情况来决定是否需要调大并发，如果 GLOBAL 级别参数不能影响正在执行的 DDL，那就没办法动态调整资源了。
另外想咨询一下，pause ddl + resume ddl 会使用新的参数来迁移数据么？如果能使用调整后的值，也可以接受。
当前您在执行 DDL 时，还遇到哪些痛点？请结合应用场景举例说明。
我遇到的最大痛点是和 MySQL 的兼容性问题，希望尽量优先将这些不灵活的限制都去掉，让 DDL 更灵活。例如：聚簇索引不支持改主键，utf8mb4 不支持转换为 utf8、AUTO_CACHE 没办法动态调整 等。其实 TiDB 现在已经支持分区表 REOGNIZE PARTITION 了，说明即便涉及到了聚簇表的重整，当前也是有办法保证一致性的，最好是将这些兼容性问题彻底解决，否则在上游 MySQL 变更时候，总还得担心 TiDB 是否支持。
还有哪些 DDL 功能是您迫切希望支持的？
支持聚簇索引转为非聚簇索引，现在聚簇索引的限制太多，十分影响一些全局索引等新功能的使用。但是现在又不支持动态转换，比较头疼
使用快速加索引功能过程中对于你们在线业务的影响这方面体验如何？
体验特别棒，加索引速度杠杠的，对业务影响也比较小。
其他反馈和建议。