在分布式数据库中，分片键（Partition Key）的选择直接影响写入吞吐。最近在压测时发现，即使表做了Range分区，如果分片键是自增ID，所有写入仍然会落到最后一个分区，导致单点瓶颈。
想和大家探讨几个问题：
- 除了使用Hash分区，还有哪些业务友好的分片键设计方案 既能避免热点，又不影响查询效率？
- 如果主表必须用Range分区（比如按时间分区归档），但业务写入集中在最新时间，如何通过二级分区或索引表打散写入？
- OceanBase的分区裁剪 在复杂查询中表现如何？比如按用户ID查订单，如果订单表是按订单ID哈希的，查询效率会下降多少？
欢迎有实战经验的同学分享你们的分片键设计案例 和压测数据 。
【标签】 #分区设计 #热点问题 #性能调优 #架构设计
5 个赞
既然是Range分区，分区键为什么要用自增列呢，那样的话所有的数据肯定都会落到最后一个分区，没有其它的键适合做分区键了么
2 个赞
ob青松
#5
自增列设置，当前插入会存在插入到一个分区的情况，超过临界值后就进入下一个分区。非业务阶段，可以根据业务特点，可以多增加分区，或者添加二级分区避免热点数据集中的情况
2 个赞
ljware
#6
将 “高频写入维度 + 打散维度” 组合成复合分片键，既保证写入均匀，又不破坏查询逻辑。
2 个赞
韩立
#8
分区应该就只有hash，range，list吧，不过一般都用拓展， range columns 等。实际使用注意配合table group
1 个赞
