- 当前使用的 TiDB 版本:
v6.5- 是否有使用过
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 功能是您迫切希望支持的?
暂无- 使用快速加索引功能过程中对于你们在线业务的影响这方面体验如何?
没什么影响- 其他反馈和建议。
无
- 当前使用的 TiDB 版本:7.5.1 8.1
- 是否有使用过
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 功能是您迫切希望支持的?暂无
- 使用快速加索引功能过程中对于你们在线业务的影响这方面体验如何?暂无
- 其他反馈和建议。尽快支持物化视图、自定义函数等功能
- 当前使用的 TiDB 版本:
v6.1
- 是否有使用过
tidb_ddl_enable_fast_reorg
(v6.5默认开启),tidb_enable_dist_task
(v8.1默认开启) 来加速索引的创建?
没有使用 tidb_ddl_enable_fast_reorg 和 tidb_enable_dist_task 加速索引创建。因为我们的系统架构相对固定,对索引的调整需求较少。而且担心开启新特性可能会带来一些未知的风险。
tidb_ddl_reorg_batch_size
和tidb_ddl_reorg_worker_cnt
在 v8.3 版本的行为变更影响是否可接受?
对于 v8.3 版本的参数变更不太了解,也没有实际感受。但从权限管理的角度看,更加灵活的设置可能会带来一些安全隐患。建议在提供灵活性的同时,加强安全管理和权限控制。
- 当前您在执行 DDL 时,还遇到哪些痛点?请结合应用场景举例说明。
在执行 DDL 时,发现对于复杂的数据类型和表关系,DDL 操作的支持不够完善。例如,在处理含有嵌套数据结构的表时,进行表结构调整比较困难。
- 还有哪些 DDL 功能是您迫切希望支持的?
希望 DDL 功能能够更好地支持复杂数据类型和表关系的处理。
- 使用快速加索引功能过程中对于你们在线业务的影响这方面体验如何?
由于未使用快速加索引功能,无法评价对在线业务的影响。
- 其他反馈和建议。
建议 TiDB 团队在推出新特性时,提供更详细的测试用例和兼容性说明,帮助用户更好地评估和应用新特性。
- 当前使用的 TiDB 版本: v6.5.3
- 是否有使用过
tidb_ddl_enable_fast_reorg
:否 tidb_ddl_reorg_batch_size
和tidb_ddl_reorg_worker_cnt
在 v8.3 版本的行为变更影响是否可接受? : 这个要看具体的业务场景- 当前您在执行 DDL 时,还遇到哪些痛点?: 无
- 还有哪些 DDL 功能是您迫切希望支持的?:无
- 使用快速加索引功能过程中对于你们在线业务的影响这方面体验如何?:没有使用过
- 其他反馈和建议: 希望支持自定义函数
这个好呀,tag的作用域又扩大了
希望tidb越来越好
1、当前使用的 TiDB 版本是 v7.0。
2、使用过 tidb_ddl_enable_fast_reorg 和 tidb_enable_dist_task 加速索引创建。最大的一个表数据量约为 600GB,该表有大约 4000 万行,42 列。使用这些特性前,加索引耗时约为 5 小时;使用后,耗时约为 2 小时。
3、tidb_ddl_reorg_batch_size 和 tidb_ddl_reorg_worker_cnt 在 v8.3 版本的行为变更影响在可接受范围内。这种变更提高了参数设置的灵活性,但也需要注意对系统性能的影响。建议在设置参数时,提供一些性能评估工具,帮助用户更好地选择合适的值。
4、执行 DDL 时的痛点是在多租户环境下,DDL 操作的隔离性不够好。例如,一个租户的 DDL 操作可能会影响其他租户的业务。
5、希望 DDL 功能能够提供更好的多租户隔离支持,确保不同租户的 DDL 操作互不影响。
6、使用快速加索引功能对在线业务的影响较小,主要是查询性能略有提升,写入速度稍有下降。
7、可以考虑增加对 DDL 操作的回滚功能,以便在出现问题时能够快速恢复到之前的状态。
1、当前使用的 TiDB 版本:v6.1
2、否,当前用的版本还不支持
4、当前您在执行 DDL 时,还遇到哪些痛点?请结合应用场景举例说明。
上下游链路问题,下游drainer同步到mysql大表ddl会重复执行导致很多mdl锁
5、还有哪些 DDL 功能是您迫切希望支持的?
无
7、其他反馈和建议。
无
1.当前使用的 TiDB 版本:v7.0
2.tidb_ddl_enable_fast_reorg用过(生产使用),tidb_enable_dist_task也用过(本地测试)线上最大的表1000W上下,25列,600MB+,耗时前13min+,处理后1min-。
3.未参与测试
4.表字段比较多的时候很难受,我这里有96个字段,不好查找,其他的数据库也不好弄,有没有什么小技巧可以快速找到列
5.自动补全
6.舒服,等待时间少,这暴脾气瞬间没了
7.希望能提供监控工具,国产化数据库监控,不单单是TiDB,也希望可以纳入其他国产数据库。
当前TiDB 版本:v6.5.10
执行 DDL 时,还遇到哪些痛点?暂无
1、当前TiDB 版本:v6.5.9
2、执行 DDL 时,发现不支持alter table name
rename? 具体是什么语句?
当前使用的 TiDB 版本:v7.5.
当前您在执行 DDL 时,还遇到哪些痛点?暂无
还有哪些 DDL 功能是您迫切希望支持的?暂无
其他反馈和建议。希望支持并行ddl
1、当前使用的 TiDB 版本:v7.5
2、否
4、当前您在执行 DDL 时,还遇到哪些痛点?请结合应用场景举例说明。
锁等待而延迟,执行时间问题
5、还有哪些 DDL 功能是您迫切希望支持的?
在线ddl,能否秒加
7、其他反馈和建议。
希望对ddl优化更多点
当前使用的 TiDB 版本:v7.5.
当前您在执行 DDL 时,还遇到哪些痛点?暂无
还有哪些 DDL 功能是您迫切希望支持的?暂无
其他反馈和建议。tidb的ddl建表等有概率卡住,只能重启tidb server解决,是否完全修复了
1、当前使用的 TiDB 版本是 v6.4。
2、使用过 tidb_ddl_enable_fast_reorg 和 tidb_enable_dist_task 加速索引创建。最大的一个表数据量约为 700GB,该表有大约 4200 万行,43 列。使用这些特性前,加索引耗时约为 5.5 小时;使用后,耗时约为 2.2 小时。
3、tidb_ddl_reorg_batch_size 和 tidb_ddl_reorg_worker_cnt 在 v8.3 版本的行为变更有一定的好处,但也带来了一些挑战。好处是可以更灵活地调整参数,但需要花费更多的时间和精力来监控和优化参数设置。建议提供一些自动化的参数调整工具,帮助用户更好地管理 DDL 性能。
4、执行 DDL 时的痛点是在高并发环境下,DDL 操作可能会导致性能下降和锁竞争。例如,在电商秒杀活动期间,进行表结构调整可能会影响系统的响应速度。
5、希望 DDL 功能能够更好地支持高并发场景,减少对业务的影响。
6、使用快速加索引功能对在线业务有一定影响,主要是在加索引期间,系统的负载会增加,需要更加小心地监控和管理资源。
7、建议 TiDB 团队在优化 DDL 性能的同时,也考虑一下对系统资源的合理利用,避免资源浪费。
- 当前使用的 TiDB 版本:V7.1 V5.4
- 是否有使用过
tidb_ddl_enable_fast_reorg
(v6.5默认开启),tidb_enable_dist_task
(v8.1默认开启) 来加速索引的创建?
V7.1.0
16.4亿537G的表加索引约40分钟,1.5T的表:
加索引耗时:tidb_ddl_reorg_worker_cnt=8,tidb_ddl_reorg_batch_size=512.
表名 | 行数 | 大小 | 耗时 | tmp空间 |
---|---|---|---|---|
xxx1 | 4388206195 | 1.5T | 106min | 99G |
xxx2 | 1640962895 | 550G | 40min | 36G |
tidb_ddl_reorg_batch_size
和tidb_ddl_reorg_worker_cnt
在 v8.3 版本的行为变更影响是否可接受?
可以接受,很好。
- 当前您在执行 DDL 时,还遇到哪些痛点?请结合应用场景举例说明。
V7 好多了。目前没有特别痛的
-
还有哪些 DDL 功能是您迫切希望支持的?
更多在线DDL功能。 -
使用快速加索引功能过程中对于你们在线业务的影响这方面体验如何?
还好。影响不大。 -
其他反馈和建议。
希望能出个统一的运维工具,管理多套集群。
1.当前使用的 TiDB 版本:TiDB v6.5.9
2.是否有使用过 tidb_ddl_enable_fast_reorg(v6.5默认开启),tidb_enable_dist_task(v8.1默认开启) 来加速索引的创建:生产环境还没有使用过,但自己测试环境验证这个功能很棒
如果有,最大的一个表有多少数据量?该表有多行?多少列?: 生产环境暂未使用,自己测试的数据量不大
使用这些特性前后,加索引的耗时分别是多少:暂无
3. tidb_ddl_reorg_batch_size 和 tidb_ddl_reorg_worker_cnt 在 v8.3 版本的行为变更影响是否可接受:行为变更对我们来说是可以接受的。虽然需要重新提交一些 DDL 任务,但长期来看,灵活性的提升对日常运维是有益的。
对于该变更,你有哪些看法和建议: 我这认为 session 级别的设置提供了更大的灵活性,这对于动态调整资源分配非常有帮助。建议在官方文档中增加更多关于这些变更的说明和最佳实践,以便我们更好地理解和利用这些特性。
4. 当前您在执行 DDL 时,还遇到哪些痛点?请结合应用场景举例说明:在高并发场景下,DDL 操作仍然会对业务造成一定的影响,尤其是在执行大型 DDL 任务时。希望能够有更多的工具和策略来减少这些影响。
5. 还有哪些 DDL 功能是您迫切希望支持的:我们希望能够支持更多的在线 DDL 操作,比如在线修改分区表结构,以及更细粒度的索引维护功能。
6. 使用快速加索引功能过程中对于你们在线业务的影响这方面体验如何:快速加索引功能显著减少了对在线业务的影响,但我们仍然需要在业务低峰期进行操作以避免潜在的风险。
7. 其他反馈和建议:希望能够有更多的监控和诊断工具来帮助我们更好地理解 DDL 操作的性能影响,以及在出现问题时快速定位和解决。此外,对于 TiDB 的版本升级,希望能够提供更平滑的升级路径和兼容性测试工具。
1、当前使用的 TiDB 版本: v8.0。
2、使用过 tidb_ddl_enable_fast_reorg 和 tidb_enable_dist_task。最大表数据量约 1.2TB,有 7000 万行,60 列。使用前加索引耗时约 7 小时,使用后约 3 小时。
3、对于 tidb_ddl_reorg_batch_size 和 tidb_ddl_reorg_worker_cnt 在 v8.3 的变更基本可接受。这确实带来了方便,但可能导致一些老系统的设置混乱。建议在升级文档中重点提示这一变化,并提供一个简单的参数检查和调整工具。
4、执行 DDL 时,遇到的痛点是在分布式系统中跨区域节点执行 DDL,网络延迟会严重影响操作速度。比如在跨国业务场景下,数据中心之间的距离导致 DDL 操作比本地操作慢很多。
5、希望支持 DDL 的分布式协调优化功能,能根据网络状况自动调整操作策略。
6、使用快速加索引功能时,在线业务在加索引期间写入延迟有一定增加,但查询波动不大。不过,对于对实时性要求高的写入业务有影响。
7、希望能有更多关于 DDL 在不同网络环境下的性能调优指南,以及针对复杂网络架构的最佳实践案例。