全网首发｜阿里资深技术专家数仓调优经验分享（上）

随着云原生数据仓库AnalyticDB for MySQL（下文统一简称：AnalyticDB）在阿里集团各个业务线、社会上各行各业的推广应用，我们沉淀了一些最佳实践，现在笔者整理在这里，供大家参考，希望对大家有帮助。本篇文章总结了AnalyticDB表的设计的最佳经验、数据写入的最佳经验、高效查询的最佳实践，以及一些常见的问题。

说明：

1.在读这篇文章之前，请先了解AnalyticDB的产品官方文档，以提前适当了解AnalyticDB；

2.本文写的最佳实践主要针对AnalyticDB 3.0，AnalyticDB 2.0在原理上也同样适用。

01 表设计的最佳实践

AnalyticDB，作为一个分布式数据仓库，能够为海量数据的实时分析带来卓越的性能体验。为了充分发挥AnalyticDB在数据分析方面的性能优势，设计表时，需要注意以下几点规则。

（一）选择合适的表类型（维度表or普通表）

· 维度表：又称广播表，是数据仓库中的一个概念，一般存储维度数据。在AnalyticDB中建表语句中有DISTRIBUTED BY BROADCAST的关键字，这些表会在集群的每个节点存储一份数据，因此维度表的数据量不宜太大，建议每张维度表存储的数据不超过2万行。

注意：维度表太大，会导致数据存储空间的膨胀，节点越多膨胀越大，同时也会导致实时写入时性能下降，IOPS会比较高。

· 普通表：也叫作分区表、事实表，一般存储业务的主题数据。普通表可存储的数据量通常比较大，可以存储千万条甚至万亿条数据，可以通过一级分区对数据做分片以及二级分区对数据进行生命周期管理。

（二）选择合适的分布键（一级分区键）

AnalyticDB中创建普通表时，默认需要通过DISTRIBUTED BY HASH(column_name,...)指定分布键，按照column_name的HASH值进行分区。

AnalyticDB支持将多个字段作为分布键。

分布键的选择依据：

• 尽可能选择值分布均匀的字段作为分布键，例如交易ID、设备ID、用户ID或者自增列作为分布键；
• 尽可能选择参与JOIN的字段作为分布键，例如进行用户画像分析时，可以选择user_id作为分布键。

注意：分布键不均匀容易导致数据分布不均，严重影响写入和查询的效率，此外也容易使单节点磁盘写满从而导致整个集群锁定不可用。除特殊的业务场景外，建表优先考虑数据是否均匀，然后再考虑JOIN KEY对齐的问题。

（三）选择合适的分区键（二级分区键）

对于表的数据量非常大的表，需要考虑创建二级分区表来对数据做进一步的切分，设置了二级分区后，也能带来两个好处：

1）对数据进行生命周期管理，比如设置了一定数量的二级分区数量后，过期的二级分区会自动被淘汰掉；

2）当查询条件带上了二级分区字段时，是可以对二级分区进行裁剪的，从而提升查询的性能。

• 直接用ds的值来做分区 PARTITION BY VALUE(ds)
• ds转换后的天做分区 PARTITION BY VALUE(DATE_FORMAT(ds, '%Y%m%d'