根据实践经验做出的权衡吧
这个是官方经过大量的性能验证，不断结合实际生产经验，评估出来的默认值96MB。
这个参数也可以按需修改，比如在百TB数据冷热归档的存储场景，我们就设置一个region为144MB，以达到最大使用性能。
专业，向大佬学习
只是一个默认设置，其实可以根据实际情况来定的。太小，文件数容易过多，太大，数据容易聚集，造成热点
我站这个解释，我觉得这个解释有理有据
region 太大的话，扫描比较慢。tikv的coprocessor扫描是以region为单位执行的。如果说一个表共960的数据，96M一个region，那么就是10个region并发扫描。
region size越小，并发扫描的线程数越多。速度越快。
但是换个角度，region size越小，tikv内部需要管理的元信息越多，占用的tikv的内存也越大，同时raft选举、心跳之类的元信息也越多，不利于整个集群的总体容量增大。
还有一点就是热点问题，如果说region越大，大量的写入越容易集中在一个region，然后这一个region挪到哪个tikv，哪个tikv的cpu就高很多。反之region越小，整个tikv的热点问题越容易解决。
就是说region size 调大还是调小，基本上就是上面几个因素相互制约，最终权衡得出一个值。
只是默认96m
官方测试出来的最佳值吧
学习了，谢谢老师的讲解。
没研究过，学习了 
都是自动分裂的哦。
region是逻辑概念，应该和写入查询没啥关系吧
有关系，极端一些就看出什么关系了：假如说一个tikv就2个region，tikv的读写请求压力很大，迁移一个region去其他节点，一下就迁移走了一半的量，如果正好这个tikv的读写请求都在这个region上，那迁移以后，原来的tikv就没有请求了，新tikv的请求压力还是那么大，也就是region迁移到哪里哪里是热点。这是region大小和热点的关系。
第二个：tidb向tikv的请求都是以region为单位请求的，tidb把所有涉及到的key按region分组后下发给tikv，如果region很大，一组数据最终分组到1个region上，那就相当于只有1个region在执行，那这个查询就比较慢，没法多节点同时读写。
coprocessor的事儿上面也说了，就是这么个事儿。
实践出的结论吧
官方参数优化的结果。
多年官方压力测试得到的结果。
Set the default region size to 1GB to improve stability
马上就1gb了
还是性能测试的结果
主要是pd有region数量限制
之前大家的业务数据没那么多
实践结果
不断测试，不断实践。
96M的设定可能是在多次测试后找到的一个平衡点，既保证了数据不会过于集中，也避免了因Region过多而导致的性能损耗。