AI 时代来了之后，你更忙还是更轻松？ 更忙了 你现在在用哪个 agent 协同平台 / 框架？ 开源的、商用的、自己攒的都行。 Claude Code 目前遇到最大的问题和阻碍是什么？ 是技术层面的（上下文、编排、调试），还是业务层面的（成本、落地场景、团队接受度）？ 时间 ，成本 有没有哪个方案让你觉得 “哎这个还不错”？ 或者反过来，“这个千万别用”？ 每天都有新的发现

更改 SQL 获取数据的方式，减少内存占用 给 TiDB 节点继续追加内存 try it

oracle 对于大事务，或者长事务，也会有相同的问题，这些经验一样可以借鉴

推荐直接上课… https://learn.pingkai.cn/learner/course

TiDB 推荐最新的LTS，建议针对性的做一些POC，具体的配置可参考官方提供的参数要求。

适应性的问题，还是需要根据场景针对获取数据的方式做一些调整的，毕竟是两个完全不同的数据库产品，产品特点和特性上还是有差距的。 可以比对执行计划，看看 AI 能否给一些建设性的建议。（最好将实际的执行计划和结果也一并提交）

能否给出一定的运维时间，专门解决这个问题呢？ 比如，停止所有服务的读写，将资源全部分配给迁移？以加速 Region 的扩容和均衡 但是，热点问题不会因为新节点的加入就可以解决的，这个一定会带来写偏斜和读偏斜，建议先解决热点问题，再来扩容。

我也兑换了一本，这书值得收藏

这个参数的定义，貌似不是这么理解的， 你的描述是 Client → TiDB → Tikv，然后 client 和 tidb 的 connect 已经关闭，如果 task close 理论上 tidb → Tikv 所有的 process 都需要停止并回收掉才对的。 可以看下原文： 在通常情况下，TiKV 处理请求非常快，只需几毫秒。但是，当某个 TiKV 节点遇到磁盘 I/O 抖动或网络延迟时，请求处理时间可能会大幅增加。在 v7.4.0 以前的版本中，TiKV 请求的超时限制是固定的，不能调整。因此，当 TiKV 节点出现问题时，TiDB 必须等待固定时长的超时响应，这导致了抖动期间…

这个有在用，版本号忘记了

上个集群资源分布看看，从 dashboard 里面可以拿到了，或者 tiup cluster 也可以

看下分区表中的全局索引，有点小复杂，看看是否符合你的要求 分区处理，有个缺点无法命中索引，所以后面追加了这个能力

写入的是啥，要写这么久

【你目前使用的版本】 V8.5.4 【最需要 v8.5.7 的哪些新功能】 SQL能力和稳定性 【还有哪些产品需求】 资源隔离，限定性隔离（少量资源可持续运行，直到运行结束产生结果）

不太好，会导致region对数据的拆分会出现问题了

多弄点资源

雪花算法在 TiDB 仍然会有热点存在，最好使用 AUTO_RANDOM AUTO_INCREMENT 可以理解为自动递增的信息，和传统数据的方式类似。这个和雪花的模式差异较大，不可混用。 否则，同一个表同一个主键又是 1 - 1000，也有可能是 999xxxx1011 , 这种跳跃可以接受么？

怎么改的，有没有详细的信息可以分享下

[image] [image] 凑个热闹，嘿嘿，居然错了一题