找到平衡点就很容易判断了 比如：隔离要素，不能因为某个业务占用了更多的资源，影响了其他的业务运行… 又比如：叠加要素，因为某个场景占用的资源较少，可以把一堆场景叠加在一起，不会影响资源不足，反而会提高利用率 你的场景是什么呢？

[image] 给你发了文档，好好看看就知道怎么解决了

哪你问的方式不对阿，应该问最大能接受 多大的 SQL 请求的长度 参考下这个，不过6.1.X 之后才有 [image]

和region 的设定有关系，这个设定又和表结构有关，建议你去看下聚簇索引和非聚簇索引 https://docs.pingcap.com/zh/tidb/stable/dm-best-practices#是否使用聚簇索引 适应什么样的场景，都需要提前规划好

[image] 这个？

通过dashboard 看下热点流量试试， 数据锁多，说明有业务层面存在冲突 region [15025515]，我建议你查下关联的是那个表，为什么会导致这么严重的冲突 [image] 这个版本量符合业务上的预期么？

上个集群状态先？

如果数据实在是丢了，为了保证集群的稳定，可以采用 unsafe 操作，也可以 recreate region 要是数据没丢，还是可以挽救一下的，3副本也不是那么容易丢数据的

单数据源更新时，异步刷新其他的多套数据格式，这样可以解决 你的担忧，但是中间服务会变得复杂点 不过性能就上去了，而且是解耦的，不影响扩展

只能考虑迁移业务， tidb 目前是不支持的 建议如下： 整理业务场景 核对数据模型 检查所有的强引用和强约束 检查所有的存储过程的应用场景 启用中间服务的方式替代相应的存储过程和强约束，强引用的逻辑… 整个过程会比较痛苦… 不过整体迁移完成之后，对于扩展能力，性能会有比较大的提高…

调整结构，优化索引，尽量使用下推的方式，实现并行计算达成提速的目标

大部分的还是走的 聚合操作，下推比较少，对 tidb 的考验比较大

上个执行计划看看，这么好的硬件资源别浪费了

CDN 没更新，现在好了

不太靠谱…

我的硬件条件使用率还不高 什么配置？

说了这么干会有问题，死活不听，非要这么干 半夜被一通电话叫醒，帮忙看怎么解决…

看起来是的，都 PANIC 了… 看日志貌似丢文件了

停电可以让你的这些设想，立马无效