【 TiDB 使用环境】生产环境 /测试/ Poc
4.0.13
【复现路径】做过哪些操作出现的问题
region数量多少合适，什么时候就应该扩容了
这个没有具体的数据，还是要看业务的，一个region 默认 96M，如果 region 太多，就会 与PD 心跳检测就多，资源交互也多。 磁盘空间 不够了，就要扩容了
好像没用具体数据，看你的资源情况吧
一般1个tikv节点不建议超过2万个region，超过可能会导致性能下降
看你们资金实力，有钱随便加多少个kv。
这个可以，哈哈哈，钞能力
现在每个tikv大概2万五千个region
就是因为没有钱，不愿意扩容，哈哈哈哈
可以找业务聊一聊，把一些用不到的数据归档后删除节约成本。
25kregion占用了多少磁盘空间
1.2T左右吧
正在缩容呢，明天缩容完看看
region数量多了以后tikv的内存使用是不是也逐渐增多了，要维护这么多region。到最后怎么处理这个内存报警，有没有碰到过这个情况呢
我们这个内存128G,使用率大概50%，到没有出现这种问题，实在不行加内存吧
有个500多G的表，准备清理数据呢
可在 Grafana 的 TiKV 面板下查看相关的监控 metrics, Thread-CPU 下的 Raft store CPU查看是否已到瓶颈，如果已超过85%，建议先用以下策略来进行调整，再考虑扩容TIKV的事情！
1.如果 I/O 资源和 CPU 资源都比较充足，可在单台机器上部署多个 TiKV 实例，以减少单个 TiKV 实例上的 Region 个数
2.通过减少 Region 单位时间内的消息数量来减小 Raftstore 的压力
3. 提高 Raftstore 并发数
4. 开启 Hibernate Region 功能
5. 开启 Region Merge 也能减少 Region 的个数。与 Region Split 相反，Region Merge 是通过调度把相邻的小 Region 合并的过程。在集群中删除数据或者执行 Drop Table/Truncate Table 语句后，可以将小 Region 甚至空 Region 进行合并以减少资源的消耗。
6.Region 默认的大小约为 96 MiB，将其调大也可以减少 Region 个数
调大region大小这个风险太大了，不敢操作，cpu资源是肯定够的，就是insert语句不稳定，有的几十毫秒，有的几百毫秒，甚至一分钟都有，应用不能接受太多300毫秒的
不过昨天扩容了一台tikv,确实300ms以上的sql减少很多，region少了肯定是有好处的
默认96M ，基本通用了