看了tidb in action，多个表的数据都会写入到rocksdb，意味着共用memtable的大小128M（flush的大小）。这么说，表的Region应该只是一个逻辑概念，实际上并没有物理上按照Region来保存数据（虽然实际上由于key的构造是按照表id+rowid来，导致最终同表同Region的数据排序后会放到一起）。那设置Region大小不超过96M有什么意义呢？只是为了以此出发Region分裂制造多个写入点吗？如果只是为了多个写入点，为什么不create table的时候增加Region的说明呢？另外，按照行数阈值触发Region分裂不会更好吗？单个Region的数据不形成独立的文件，那么统计其空间大小我感觉是不好做的（虽然我现在还不知道tikv是怎么统计一个region用了96MiB空间）。我是从应用开发角度来思考这个问题，感觉有点不解。
可能是基于性能与资源开销的平衡,可扩展性与灵活性以及限制条件等多方面因素的综合考虑。
- 性能平衡：适当大小的 Region 可以平衡数据分布和查询性能。过小的 Region 会导致 Region 数量过多，增加资源消耗和性能下降；过大的 Region 则可能导致性能不稳定和查询性能下降。
- 资源消耗：过大的 Region 可能导致资源消耗过多，影响 TiKV 的性能。
- Region 调度：过大的 Region 可能导致 Region 调度变慢，影响数据的均衡性和性能。
96 MiB 是一个推荐的默认值.
你可以根据实际情况和需求来调整 Region 的大小。根据文档建议，Region 大小的推荐范围是 [48MiB, 258MiB]，常用的大小包括 96 MiB、128 MiB 和 256 MiB。避免将 Region 大小设置超过 1 GiB，以避免性能波动和查询性能下降的情况发生。
Region是个逻辑上的概念，rocksdb本身没有这个概念，数据存储也没有用到这个。
region是分布式数据库用来做调度的单位
这些都是笼统的说法，有没有实验数据说明这个Region的设置能够让系统性能更好呀。
我之所以提这个问题，是因为每个表的情况不一样，划分Region应该是根据表的情况来确定。譬如有些表它就是插入一次，然后就静态了，而且数量不多，你管他那么多，就放一个region里面就好了呀。有些表经常删减变动，需要大量导入数据，那肯定维持多个region，才能体现分布式效果。把这个region的设置放到db的层面是否有些鲁莽呀？
即使是静态表，就一个region的话，读取性能也会受影响。
region大小默认96M，region太大或太小都不太好。有合并或分割的情况。会有一个范围值，触发相应的操作。
理论联系实际，现实生活中也有许许多多的类似情况。
Region太大太小都不好，需要均衡考虑，其他分布式也类似，就比如MONGODB一个chunk大小是64M
肯定是“权衡”下的“建议”默认值，都也留了“口子”允许调整，做产品应该都是这思路，“按业务需求”调整 region 大小，数据库没有办法穷举
96M应该是默认设的值，不是一个新region初始的值。
96MB，来源于网络传输优化的经验，
1000MB 的网络，传输大概是 9.6 mb/s，
然后 1W MB 的网络，传输大概是 96 mb/s，
刚好是一个region 的大小，这样有利于调度和并发，不会超过这个界定的大小，避免受限于网络上的物理限制，是最大的优化方案。
所以，生产的tidb 集群推荐的是 双 W 兆的网卡。
供你参考！
8 个赞
原来如此，像大佬学习~！
关于为什么不在 CREATE TABLE 时指定 Region 的大小或按照行数阈值触发 Region 分裂，主要考虑如下：
灵活性：动态调整 Region 的大小和分布可以更好地适应不同工作负载的变化，而不需要预先知道每张表的数据特性和访问模式。
系统级优化：由系统自动管理 Region 的分裂和合并，可以避免用户需要深入理解底层存储细节，使得 TiDB 更易于使用和维护。
至于如何统计一个 Region 占用的空间，TiKV 通过监控每个 Region 的元数据信息（如已使用的存储空间）来实现。这包括跟踪每个 Region 的写入和删除操作，以及定期进行的垃圾回收过程。这些信息可以帮助系统实时了解每个 Region 的当前状态，并据此做出分裂或合并的决策。
1 个赞
系统的默认值是96M，可以修改参数改变这个默认值。
各位大佬的回答对我都很有帮助，谢谢各位大佬。
96m估计也是不断测试，找到的一个适合的值。
应该是 raft协议复制的考虑