你就会发现已经连续100天都打了卡

VMware 装 TiDB ，硬件性能会不会有点儿过于弱？

问题 1 TiDB 集群故障时，我最希望 TEM AI 智能运维能帮助解决这些具体问题： 1）自动根因定位：不用人工翻日志、查监控，直接告诉我是 PD / TiKV / TiDB Server 哪一层出问题，是网络、磁盘、锁冲突、热点还是资源瓶颈。 2）故障自动止损：例如自动切流量、隔离异常节点、自动重启异常组件，避免业务雪崩。 3）恢复建议：给出可执行的恢复步骤 4）跨组件关联分析：把监控、日志、慢查询、调用链自动关联，自动画出故障传播链。 5）减少误告警：AI 自动过滤噪音告警，只报真正影响业务的问题。 问题 2 慢查询方面，我希望 TEM AI 提供具体分析 + 优化能力： …

blkid /dev/sdb 查不出来吗？

明显还是用 tidb-lightning 比 source 更好。产品设计上，source 是兼容 mysql 数据库，tidb-lightning 用于导入 dumpling 生成的文件

近期还会上别的周边不？

恢复时没有校验集群是否存在库的步骤，但是元数据库（mysql）是否会有影响可能得验证一下

你现在用 TiDB 时，最卡业务、最费人力的问题是什么？ 故障诊断，某些性能问题如22点数据库响应延时增加10ms，定位问题根因，故障问题如会话链接异常存在10天，定位问题根因等等，还是抓耳挠腮 如果加一个新功能就能少加班、少踩坑、少花钱，你最希望是什么？ 全链路跟踪与诊断 什么功能一旦上线，会让你更愿意升级 / 付费企业版？ 全链路跟踪与诊断

没有这样的接口暴露出来。把 pd 部署到有 etcd 的机器上有可行性吗？

tidb_enable_lazy_cursor_fetch = on 就是数据库侧的流式吧？不过当前是实验特性

performance_schema.session_connect_attrs 记录有没有帮助？

单纯做实验，tiup playground 比 docker 更方便、更自由

据说 9 版本向量能力会进一步释放，预计 3-4 月份

携手奔赴下一个十年！

你是从哪个数据库迁移到 TiDB 的？ 迁移 TiDB 都用啥工具？偏爱 TiDB 原生的 DM、Lightning、TiCDC，还是习惯用 DataX、Flink 这些第三方，或者自己自研工具？ 源主要是 Oracle、兼容MYSQL协议数据库 ，使用的工具包括两种：DSG 以及 DM 不用 TiDB 原生迁移工具的小伙伴，是因为技术栈适配难、性能不够，还是觉得易用性一般？大家最希望 TiDB 迁移工具加啥实用功能？ TiDB 自己的迁移工具 TMS 产品能力略弱于 DSG，DM 对于非原生 MySQL binlog 格式的数据库不支持，所以需要原生外的工具 实操 TiD…

围观ing [Weixin Image_20260116092456_12_2568]

已预约 [Weixin Image_20260109091543_11_2568]

您当前使用的云资源部署在哪个地域（城市），会考虑单一城市部署还是多城市容灾？在哪朵云上？ 私有。目前跨城基建当前正在建设中 目前运行着多少套 TiDB 集群，合计节点数 / 核心数（core）为多少？您当前 TiDB 相关资源的年度总费用是多少？ 云提供的具体折扣力度（如折扣率 / 优惠方式）是什么？ 已经上百套 若迁移至 TiDB 全托管服务，您期望获得的服务等级协议（SLA）标准是什么（如可用性、故障恢复时间等）？ 暂时不会考虑全托管，主要是安全要求

1.你所在企业是否有出海规划或已开展出海业务？企业出海的核心目标区域 / 国家是哪里？ 有的，优先北美和东南亚 2.驱动企业出海的核心因素是什么（如市场扩张、政策支持等）？ 多方面原因，除政策支持外，企业自身也有市场扩张和多元化经营的需求 3.出海场景下，你最关注数据库的哪些能力（如合规适配、跨区域部署、低运维等）？最关注的技术问题是什么？ 首先关注成本与便利性，其次是性能和稳定性。最关注的技术问题是安全，特别是数据合规 4.出海场景下，你更倾向选择自建数据库还是全托管数据库服务？ 优先托管，其次自建 5.出海业务中，你会选择 TiDB 吗？ 必须会