【 使用环境 】生产环境
【 OB or 其他组件 】OB
【 使用版本 】CE 4.1.0.0
【问题描述】
对于Primary Zone 为 RANDOM的场景，应该怎么样选择分区字段呢，如果使用业务常用的条件字段使用list分区，业务的sql经常会带此字段进行操作，可以避免分布式事务但是可能会造成分区大小分布不均衡且不能发挥数据库的能力，如果使用hash这种方式均衡打散又会带来分布式事务的问题。
【复现路径】问题出现前后相关操作
【问题现象及影响】
【附件】
hash分区，对于精准数据操作比较友好。也就是说CRUD操作中，都带有明确的hash分区的字段值，这样每次都会直接路由到对应的分区中，从而提升sql执行效率。
当然，如果数据量比较大的情况下，也可以考虑使用range对date字段进行分区。
在避免分布式事务和利用并行能力的取舍问题，有没有最佳实践呢
通常在存储用户信息的时候，会使用用户号这种区分度比较高的字段做hash分区。
对于流水、历史数据等，使用日期做range分区，再根据用户号做hash分区。
这是一般情况会这么做，也要根据系统实际情况进行分析调整，看系统适合什么样的分区方式，适合选择哪个字段进行分区。大的选择标准就是，能够保证尽可能多的sql性能比较好。
hash分区是可以做到均衡分布的目的，但是是否会带来分布式事务的问题呢，比如我一个地区的用户id都是1开头的，在业务sql中，会尽量保证对一个地区的用户进行操作，那hash打散primary zone到不同zone的话，对于DML操作，不就产生了分布式事务，需要到不同的zone的primary上进行操作
所以要尽可能降低批量数据更新的次数，更换为精准的数据更新。如果实在没办法避免，也是可以有分布式事务的。
在一个tp类应用中，更多的数据操作会是精准的数据操作，所以，做hash分区，会对精准数据操作sql提升比较大，通常也是要重点保障的场景。
分布式数据库，更多的是要做选择，做权衡，总要舍弃些东西的。而且，所谓的最佳实践，不一定适合所有场景，都要根据自己的情况进行不断调整，优化，才能做到更好。