【你使用的是 TiDB Operator 还是其他方式部署 TiDB？】 二次开发 tidb-operator、tiup 都有 【在 K8s 上部署 TiDB 的主要应用场景是什么】 和应用场景无关，更多是成本考量。目前是按重要性逐渐迁移任务到云上 【你认为容器化 K8s 部署 TiDB 有哪些优势和挑战？】 优势是：最大好处是资源可以更合理的使用 挑战是：架构更复杂了，问题分析更困难了

与 盘的类型 没有关系，我们这里直接禁用了这个参数

十年砥砺，PingCAP 以 TiDB 拓数据库新境，创新不止。愿未来继续逐光前行，再谱华章，引领行业新高度！ 印象最深的事情：感谢多年前同事介绍了并认识了TiDB

如果你目前还没有使用公有云服务，可以一起来聊聊： 企业安全方面的要求不会使用公有云，不过内部的云平台已经相对问题，公司已经在大力推云上使用云上提供的服务，目前主要以paas 和 saas 的形式提供给应用方使用

【数据库层面的降本增效你有哪些经验/建议？】 目前最大的体会是要尽量避免架构的滥用，避免想用而用，而是要适合用而用 【个人体感：用 TiDB 是否能真正做到降本增效？】 适合的场景确实可以降本增效

【2025 年，你有新场景、新系统、升级的规划吗？】 有，很多 5、6版本的数据库要EOS，需要升级 【TiDB 路线图和你当下需求的契合度】 部分功能特性还是比较贴合需求的，例如全链路监控、全局索引 【对 TiDB 的产品迭代有哪些期待？】 目前对于稳和快需要求比较高：稳说的是优化器能更好，少一些突然的惊喜。快是说，希望TiDB能仅一步提升性能，包括TP和AP的能力。

我之前认识不对了，以为 ddl 也属于事务语句

有事务DDL的概念，google 了一下 Google F1 Online Schema Change，看到的答案也是其不算事务 ddl 算法，

我以前通过拼sql 查看 show create user 和 show grants for 获取创建用户的语句和用户授权的语句

落后直接调整基本没问题，主要是 pd leader 配置 tso。超前会麻烦些

麒麟v10 sp1，存量改造和新增的基本都是这个了

这里的“最小配置”不是技术硬限制，而是“经验推荐”。要看需求是什么，如果是功能验证、简单的性能测试，降低配置也没问题，满足需求就可以

我也模拟试试

是偶然的现象吗？如果要复现有什么注意事项吗

95% 都是 java，少部分 go 或者 python，C绝迹了

感谢分享，正在测试

个人目前最大的感受是：要确定方向，充分利用碎片时间

操作： 1）tidb v6.5.11 升级至 v8.5.1， 2）搭建 cdc 复制链路，v8.5.1 → v6.5.11 3) 将 v8.5.1 版本 cdc 进行 patch 到新架构的版本 4）修改集群配置，增加 newarch: true，对 cdc 执行 tiup cluter reload 操作 报错信息 1）程序 panic [image]

下意识会按 mysql 中的schema 来理解