云原生数据仓库AnalyticDB：算子级别诊断结果

聚合算子的聚合度一般指GROUP BY分组聚合操作中的输入数据量和输出数据量的比值（即InputDataSize和OutputDataSize的比值），该值越小表明聚合度越低，聚合效果越差。在AnalyticDB MySQL版中，分组聚合操作一般分为两步：初步聚合（PARTIAL）和最终聚合（FINAL）。如果聚合算子分组的个数较多，会导致聚合度低，那么在第一步的初步聚合操作中，不但不能减少网络数据传输，反而会消耗大量的计算资源。

可以考虑跳过初步聚合操作，直接在各个节点间对数据进行重分布，之后直接进行一次最终聚合。更多详情，请参见分组聚合查询优化。

• 如果是查询语句使用了Hint或集群使用了配置，导致的过滤条件下推功能关闭，请检查使用该Hint或配置的原因并判断是否可以取消该Hint或配置。更多详情，请参见过滤条件不下推。
• 如果是使用了函数，可以考虑是否直接使用该函数写入数据，而在查询时去掉函数。
• 如果是过滤条件中的相关字段没有索引导致过滤条件没有下推，那么需要检查没有索引的原因。

Join的数据膨胀率是Join的输出行数与Join的输入行数的比值，其中Join的输入行数为左表行数与右表行数之和。对于合理Join条件，一般Join的输出行数会小于输入行数，如果Join的输出行数大于输入行数，那么会存在Join数据膨胀的问题，Join数据膨胀会导致较多的计算资源和内存资源被占用，导致查询较慢。

• 如果是数据本身特征导致的Join数据膨胀，例如左右表都大量存在的相同的值，可以考虑在表过滤阶段将这些相同值都过滤掉不参与Join。
• 如果是不优的Join顺序导致的数据膨胀，可以考虑手动调整Join顺序。调整方法，请参见手动调整Join顺序。

建议将Left Join优化改写成Right Join。改写方法，请参见Left Join优化改写为Right Join。

Cross Join，即没有Join条件的Join操作，输出的行数是左右两表行数的乘积。如果左右表都较大，会极大地影响AnalyticDB MySQL版集群的稳定性。

考虑增加Join条件，消除Cross Join。

扫描算子会在AnalyticDB MySQL版的存储层进行数据的过滤和明细数据的读取，如果SELECT的字段个数较多，需要读取的明细数据也较多，那么就会占用较大的磁盘I/O资源，影响AnalyticDB MySQL版集群整体稳定性。

可以优化SQL语句，减少SELECT语句中不必要的字段。

AnalyticDB MySQL版是分布式执行架构，大表的数据一般需要指定分布字段，数据写入时根据分布字段分散到不同的存储节点上。如果分布字段的值分布不均匀，那么数据存储在各个节点上时也会不均匀，最终导致数据读取时，各个节点在读取数据时存在时间上的长尾，影响最终的查询效果。

通过选择合适的分布字段来减少表扫描数据量的倾斜。优化方法，请参见分布字段合理性诊断。

AnalyticDB MySQL版在使用索引进行数据过滤时，若需要过滤的字段过滤度（即过滤算子的输出数据量和输入数据量的比值）较低时，使用索引不一定能获得预期的过滤效果。

可以考虑不下推过滤条件，而在计算节点中直接执行过滤操作。更多详情，请参见过滤条件不下推。