1. 查询流程和执行计划
• SQL语言完成用户和系统内部存储数据之间的交互。在执行阶段，AnalyticDB MySQL版中的查询，会首先被切分为多个Stage来执行，一个Stage就是执行计划中某一部分的物理实体。
• 在AnalyticDB MySQL架构中有三层：接入层、计算层、存储层，是计算存储分离架构。一条SQL语句执行过程，首先会进入接入层，经过解析器完成语句的解析生成执行计划，优化器对执行计划进行优化，形成逻辑执行计划。
分组聚合查询的处理流程，Controller节点会把查询的逻辑执行计划（Plan）分片下发到执行计划任务的各个节点上。
• Stage2由4个Task组成，并行执行数据的扫描、过滤以及局部聚合等操作。
• Stage1由2个Task执行，并行执行最终的聚合操作。
• Stage0由1个Task执行，负责汇总Stage1的2个Task生成的最终聚合结果。
2. 算子
一个算子负责完成一个基本的数据处理逻辑，一组算子按照执行计划完成数据的一组处理规则，参数名称与功能如下：
• Aggregation：通过sum()、count()、avg()等函数对数据进行聚合或分组聚合操作。
• DistinctLimit：对应SQL语句中的DISTINCT LIMIT操作。
• Filter：使用存储层数据的索引进行过滤。存储层数据没有索引，需要在计算层使用Filter算子进行过滤。
• Join：对应SQL语句中的Join操作。
• Project：对应SQL语句中对特定字段的投影操作，例如case when then控制流、concat()函数等。
• StageOutput：用于将当前Stage处理后的数据通过网络传输到下游Stage的节点。
• Sort：应SQL语句中ORDER BY子句的操作，执行ORDER BY字段的排序。
• TableScan：用于从数据源读取数据，如果需要过滤数据，那么数据过滤由底层数据源使用索引高效完成。
• TopN：对应SQL语句中的ORDER BY LIMIT m，n查询。
3. 影响查询性能的因素
影响查询性能的因素有：集群规格、节点数量、数据分布特征、数据量大小、查询并发度、查询复杂度。
1) 集群规格
• 不同集群规格的CPU核数、内存大小和数据存储介质等属性不同，处理子任务的能力也就不同，需要结合业务查询特征来选择集群规格。
• 以Join或分组聚合为主的业务查询会消耗较多的CPU和内存资源。
• 扫描数据和简单分组聚合操作的查询会消耗较多的磁盘I/O资源。
2) 节点数量
• AnalyticDB MySQL版使用了分布式数据处理架构，一条查询会被分解成多个Stage在不同的节点上并行执行。所以如果集群中的节点数量越多，AnalyticDB MySQL版处理查询的能力也会越强。用户可以根据实际的业务需求来决定集群节点的购买数量，更多详情，请参见创建集群。
• https://help.aliyun.com/document_detail/122234.html
3) 数据分布特征
• 由于使用了分布式数据处理架构，具备将一条查询分解到多个节点上并行执行的能力。
• 充分利用多节点来并行处理查询，还取决于数据在存储节点上的分布特征。
• 如果数据能够均匀分布在存储节点上，多个子任务在处理数据时，就能几乎同时结束任务。
• 数据分布不均匀，子任务在处理数据时会存在时间上的长尾，从而影响最终的查询效果。
4) 数据量大小
• 在处理查询时，通常不会将处理过程中的临时结果暂时写到磁盘里，而是尽量在内存中将所有数据处理掉。
• 如果查询需要处理的数据量较大，就可能会长时间占用大量的资源，导致整体查询效率降低，进而影响最终的查询效果。
• 表存储的数据量较大，在执行索引过滤、明细数据读取等操作时会出现争抢磁盘I/O资源，导致查询变慢。
5) 查询并发度
• 能同时处理的查询数量也会存在上限。如果查询的并发度过高，集群节点资源已到达瓶颈，那么后台的查询就会出现较长时间的排队，影响整体查询效果。
6) 查询复杂度
• 查询的复杂度不同造成的压力也不同。
• 如果查询中过滤条件过于复杂，会在数据过滤时对存储节点造成一定压力。
• 如果查询中Join算子过多，数据可能需要在不同节点间进行多次的网络传输，造成网络阻塞。
• 如果查询中分组字段过多，也会占用较多的内存资源。
更多精彩内容，欢迎观看：
《阿里云认证的解析与实战-数据仓库ACP认证》——云原生数据仓库AnalyticDB MySQL版解析与实践（下）——三、SQL优化与慢查询解决（下）：https://developer.aliyun.com/article/1222968?groupCode=certification
