可以查询热点表：information_schema.tidb_hot_regions 或者pdctl看看hot region

首先需要确定是热点问题造成的。 正常情况下，新版本有一定的自动调节region的能力。 如果需要手动打散，可以先通过Dashboard热力图或其它方式确定热点表，考虑使用split打散观察。 Split Region 使用文档 | TiDB 社区版

TiDB 备份与恢复概述 | TiDB 社区版 参考。

分布式的数据库设计思想都是者不多的。底层就是各家实现各家的。

这个有结论了么？向了解怎么处理。tidb针对时钟被调整是怎么处理的 ？

看自己参数设置的大小。设置的多就占的多，设置的少就占的少。

请描述问题。

灵活扩缩容； 没有单点的顾虑；

赞一个。写的很详细

赞一个。

第一怀疑是表配置了Placement rules，只能在这三个store上。

如果只使用tidb的话，就是搞一个宽表吧，或者如果表里有类似时间的字段，将当日之前的数据先group了，最后实时跑的时候，就是计算的结果，sum上，今日的数据的group，如果数据不能区分估计就不能这样搞。 要不就增加tiflash节点试试。

[image] 看着繁忙的智能体-活动标签，都是在回复后自己在思考总结会话，所以新的输入消息就都被阻塞了。 首先，这个总结不是用户发起的。其次，如果要总结，可以在后台异步总结，不要阻塞会话。 其次，4个插件的配置能否针对常规厂商给个配置样例。有的配置的有问题，也没有错误提示，就是单纯的对消息不响应。

SQL也很简单，要是都没发调整，就看看group 操作是否能提前计算历史的，然后累积新数据的group，类似数仓的设计思想。

[微信图片_20260526161307_7_213] 你认为未来的工作方式是怎样的？ 对于产品设计、开发等都可以使用AI 协同工作。但是不太了解在对数据库方面的助力，目前还是再把AI当做搜索引擎再使用。

如果库整体负载不高，可以考虑开一会generallog看看。

建议测试，像其他一些cdc的的同步，做了类似的操作后多数也得重新启动下进程，重新加载元数据才行。

看看各个节点的启动是不是都通过tidb启动的。

只要副本设置为3，就没有影响，TiDB的基础功能。