统计信息并发收集、分区表全局索引

终于等待他了

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的执行，但是效果不是可预期…

–no-view 导出有问题？

目前处理的核心的思想第一步是缩小故障排查范围，确定导致问题的第一责任组件。第二是查看责任组件的日志，分析故障时刻的日志。一般到这里就差不多了。对于分析日志无法定位的问题，优先 ASKTUG、其实尝试理解代码。实际中大不数问题都是重复的，例如SQL 执行oom、应用到数据库链接断开等等

[quote=“社区小助手, post:1, topic:1033156”] 【你最想实现的 TiDB 功能需求】 最希望能体系化的故障处理和性能优化方案，类似 oracle 的等待事件、awr。当然当前TiDB也有很多参考方法、手段。只是即使解决了，每次都是有点儿“玄学”的意思。我有一个朋友，他说“易入门但难真精通” 【你最喜欢的 TiDB 新特性 + 理由】 最喜欢 dashboard 和 tiup。dashborad 特别是其中的 SQL 语句分析，对于日常 SQL 的性能分析帮助很多，tiup 个人觉得是目前的主流分布式数据库做的最好的 【你最想要周边心愿池里的哪个周边】 T…

场景需求 目前业务有需求“同城双活”。TiDB 目前的解决方案是 DR-AUTOSYNC 或 Ticdc，但 corner case 其实这两个方案都不具备“真正双活”的能力，它不能 100% 保证两个中心的数据一致性。业界参考解决方案其中之一是使用“共享存储”，同城双中心的两套集群共享一份数据，理论上可以满足业务对数据库“双活的需求” 痛点描述 直通 ssd 目前有两个问题：1是可靠性待提高：单盘不具备硬件冗余性而双盘冗余，如果是“硬” raid 需要专门 raid 卡支持，如果是软 raid，可靠性和成本又会增加。 2是磁盘资源可能会浪费。共享存储可以避免这些问题 功能需求 1）…

1.锁历史记录查询 2.SQL执行全链路诊断 3. cluster_statements_summary|history|evited 三张表数据归并以及历史记录保存

已投票。早知道有这活动，我也提前在这里提需求了

tiup display 看一下集群的状态，以及看一下 tidb.log

tidb 木有插件的功能，考虑把 tidb 的数据同步到其它组件中计算吗

bug https://github.com/pingcap/tidb/issues/53292

[image] 目前仍旧不支持

场景描述 场景很多，比如现金管理、报表生成 痛点描述 目前 TiDB 的大数据量下多表 join 的性能还不能 100% 满足业务需求，10表+ 的关联比较常见 功能描述 对我们来说，稳定与性能有限，功能点其次。手动更新有意义，但需要看具体操作和使用要求，运维和开发的界限还比较严格 使用意向 “先提供手动更新功能，您会在业务中使用吗”，要依赖使用要求 “动修改 SQL 以访问物化视图，您会在业务中使用吗”，应该可行，但也要看改动的成本有多少，透明肯定是最希望的

“命令用2.4.0”是什么意思？下游的kafka 版本实际是 2.4.0，而不是create changefeed 里面写的 2.3.0？ [image] 文档上 8.1 的 ticdc 支持 2.1 以后的 kafka

希望推送技术原理、故障解决和性能优化实际案例。除了推送评率，也安利考虑文章篇幅

asktug 搜搜这个参数，帖子还挺多的

需要充分测试，见过两种问题：1是 耗费内存可能更多 2是执行计划可能受影响

你这是编辑模式下的操作的吧。不过这方式倒是比直接改文件友好