必须指定表分布（DISTRIBUTE BY），表分布策略选择的原则如下：

目前提供REPLICATION和HASH两种表分布策略。REPLICATION分布会在每个节点保留一份相同的完整的数据表。HASH分布会根据所提供的分布键值将表数据分布到多个节点中。

对于系统配置表、数据字典表等数据规模小于2000w且插入更新十分低频的表，要求建议采用REPLICATION分布。

慎用REPLICATION分布，该分布表会造成空间膨胀、DML性能下降等负面影响。

对于数据量较大，更新频率较高的表，必须进行数据分片，要求采用HASH分布策略，分布键必须建议是主键中的一个或多个字段。

合理设计分布键，既考虑查询开发的便利性，又要考虑数据的均匀存储，避免数据倾斜和读热点。

Hash表的分布键选取至关重要，如果分布键选择不当，可能会导致数据倾斜，从而导致查询时，I/O负载集中在部分DN上，影响整体查询性能。因此，在确定Hash表的分布策略之后，需要对表数据进行倾斜性检查，以确保数据的均匀分布。

应使用取值较为离散的字段作为分布键，以便数据能够均匀分布到各个DN中。
在满足条件1情况下，存在常量过滤的字段不建议成为分布键，否则会使得所有的查询任务都会分发到唯一固定的DN上。
在满足条件1和2原则下，尽量选择查询中的关联条件作为分布键，这样可保证JOIN任务的相关数据分布在相同的DN上，减少DN间数据的流动代价。

尽量避免数据shuffle。shuffle，是指在物理上，数据从一个节点，传输到另一个节点。shuffle占用了大量宝贵的网络资源，减小不必要的数据shuffle，可以减少网络压力，使数据的处理本地化，提高集群的性能和可支持的并发度。通过对关联条件和分组条件的仔细设计，能够尽可能的减少不必要的数据shuffle。

由于数据库规格要求HASH分布表的主键必须包含其分布列，因此在选择分布列时，也可以考虑选择表的主键作为分布键。

表1 常见的分布键及效果

分布键值	分布键分布均匀性
用户 ID，应用程序中有许多用户。	好
状态代码，只有几个可用的状态代码。	差
项目创建日期，四舍五入至最近的时间段（例如，天、小时或分钟）。	差
设备 ID，每个设备以相对类似的间隔访问数据.	好

分布键使用的列长度不易超过128，过长会带来较高的计算开销。
分布键值一旦插入不允许更新（UPDATE），如需更新需删除后插入。
视图不允许嵌套。

一方面，如果视图编写时使用了通配符，当被调用的视图新增或删除列时，视图将发生错误。

另一方面，视图嵌套可能因无法使用索引而执行效率低下，尽量使用带有索引的基表而不是视图上做关联操作。

分布键不建议超过3列，列数过多将带来较高的计算开销。
视图定义中尽量避免排序操作。

ORDER BY子句在顶层视图上无效，如果必须对输出数据排序，请考虑在调用视图中使用ORDER BY。

父主题： 数据库设计规范

同意关联代理商云淘科技，购买华为云产品更优惠（QQ 78315851）

内容没看懂？ 不太想学习？想快速解决？ 有偿解决： 联系专家