目录
分区设计原则
分区维护
存储方式及分布键规范
分区设计原则
表分区用于解决数据量特别大的表的问题，比如事实表，解决办法就是将表分成很多小且更容易管理的部分。
表分区参考以下几个原则
（1）表是否足够大？只有非常大的事实表才适合做表分区。若在一张表中有数亿条记录，从逻辑上把表分成较小的分区将可以改善性能。而对于只有数万条或者更少记录的表，对分区预先进行的管理开销将远大于可以获得的性能改善。
（2）对目前的性能不满意？作为一种调优方案，应该在查询性能低于预期时再考虑表分区。
（3）查询条件是否能匹配分区条件？检查查询语句的WHERE条件是否与考虑分区的COLUMN一致。例如，如果大部分的查询使用日期条件，那么按照月或者周的日期分区设计也许很有用，而如果查询条件更多的是使用地区条件，可以考虑使用地区将表做列表类型的分区。
（4）数据仓库是否需要滚动历史数据？历史数据的滚动需求也是分区设计的考虑因素。比如，数据仓库中仅需要保留过去两个月的数据。如果数据按照月进行分区，将可以很容易的删除掉两个月之前的数据，而最近的数据存入最近月份的分区即可。
（5）按照某个规则数据是否可以被均匀的分拆？应该选择尽量把数据均匀分拆的规则。若每个分区储存的数据量相当，那么查询性能的改善将与分区的数量相关。例如，把一张表分为10个分区，命中单个分区条件的查询扫表性能将比未分区的情况下高10倍。
分区维护
（1）分区清空
分区的清空操作统一使用truncate操作。
（2）分区删除
基于合理管理和控制分区数量的原则，针对可删除的历史数据可以通过drop分区的方式删除。如：需要删除24个月之前的数据可以直接drop掉24个月之前的分区。
（3）分区创建
分区由脚本负责创建，每个脚本中都包含分区创建的内容，根据实际的执行日期自动创建对应的分区。
按月分区以及按日分区的表，都采用使用前检查分区是否存在，如果不存在则创建的方式。
建议针对日分区表，每日预创建2天后的分区；对于月分区表，每月月底创建下月的分区。
存储方式及分布键规范
（1）优先使用列存作为数据表的默认存储方式。
（2）优先使用hash作为数据表的默认分布方式。
（3）根据实际需要，优先在PK、常用关联字段作为数据表的分布列。
（4）创建数据表(包含临时表)时必须指定存储方式、分布方式、分布列。
（5）为减少交易等流水级数据与账户表等主表之间的连接运算时的资源开销，尤其为减少节点之间的数据传输，应将这些流水数据按照与主表同样的Hash分布键进行数据分布。
（6）分布键只支持字符型与数值型。支持类型如下：
varchar,decimal,int,bigint,smallint
