本文介绍影响AnalyticDB MySQL版查询性能的因素。

背景信息

  • 集群规格

    AnalyticDB MySQL版集群支持多种规格(更多详情,请参见规格),不同集群规格的CPU核数、内存大小和数据存储介质等属性不同,处理子任务的能力也就不同,因此您需要结合业务查询特征来选择集群规格。例如,以Join或分组聚合为主的业务查询会消耗较多的CPU和内存资源;而以扫描数据和简单分组聚合操作为主的查询则会消耗较多的磁盘I/O资源。资源类型消耗量的不同会导致不同规格的集群存在不同的性能瓶颈,最终影响整体的查询效果。

  • 节点数量

    AnalyticDB MySQL版使用了分布式数据处理架构,一条查询会被分解成多个Stage在不同的节点上并行执行。所以如果集群中的节点数量越多,AnalyticDB MySQL版处理查询的能力也会越强。您可以根据实际的业务需求来决定集群节点的购买数量,更多详情,请参见创建集群

  • 数据分布特征

    由于使用了分布式数据处理架构,AnalyticDB MySQL版具备将一条查询分解到多个节点上并行执行的能力。但AnalyticDB MySQL版能否充分利用多节点来并行处理查询,还取决于数据在存储节点上的分布特征。如果数据能够均匀分布在存储节点上,那么AnalyticDB MySQL版中的多个子任务在处理数据时,就能几乎同时结束任务,实现理想的查询处理;如果数据分布不均匀,那么子任务在处理数据时会存在时间上的长尾,从而影响最终的查询效果。

  • 数据量大小

    AnalyticDB MySQL版在处理查询时,通常不会将处理过程中的临时结果暂时写到磁盘里,而是尽量在内存中将所有数据处理掉。如果查询需要处理的数据量较大,就可能会长时间占用大量的资源,导致整体查询效率降低,进而影响最终的查询效果。

    此外,如果AnalyticDB MySQL版中表存储的数据量较大,那么在执行索引过滤、明细数据读取等操作时也会出现相互争抢磁盘I/O资源的情况,导致查询变慢。

  • 查询并发度

    由于集群规格和规模的限制,AnalyticDB MySQL版能同时处理的查询数量也会存在上限。如果查询的并发度过高,集群节点资源已到达瓶颈,那么后台的查询就会出现较长时间的排队,影响整体查询效果。

  • 查询复杂度

    查询的复杂度不同,对AnalyticDB MySQL版造成的压力也不同。例如,如果查询中过滤条件过于复杂,会在数据过滤时对存储节点造成一定压力;如果查询中Join算子过多,数据可能需要在不同节点间进行多次的网络传输,造成网络阻塞;如果查询中分组字段过多,也会占用较多的内存资源。