本文介绍调优过程中常见的问题及答案。

写入性能问题

  • Q:如何在AnalyticDB MySQL版中合理建表?
    A:建表时,需要注意以下几点:
    • 分布字段的选择。AnalyticDB MySQL版是分布式数据库,数据需要根据分布字段均匀地分布在各个后台节点才能保证尽可能高的利用资源。分布字段选择不合理,会导致写入时存在热点,降低写入性能。
    • 分区字段合理性。AnalyticDB MySQL版后台以分区为粒度进行文件的存储、索引的构建以及查询。每个分区的数据行数过少,可能导致查询时扫描的二级分区数较多,降低扫描性能;如果每个分区的数据行数过多,可能频繁触发该分区的索引构建,所以合理的二级分区对系统整体稳定性非常重要。
    • 复制表合理性。复制表在每个后台节点都保存一份,好处是在需要和复制表进行JOIN时,不需要对复制表进行网络传输,提高系统的并发处理能力。但对复制表进行增删改时,会对涉及的数据行进行重复多次的操作,以保证每个复制表的副本都生效。所以复制表不宜过大,也不宜对复制表频繁进行增删改查操作。

    更多信息,请参见数据建模优化

  • Q:为什么写入峰值下降了,但是CPU没有降下来?

    A:AnalyticDB MySQL版会对写入的数据实时地构建索引,以加速查询。构建索引需要消耗一定的系统资源,特别是在有写入峰值导致写入量暴增时,索引构建过程更加占用资源。

  • Q: AnalyticDB MySQL版的查询性能为什么比RDS慢很多?

    A:AnalyticDB MySQL版做为分布式系统,其优势在于利用多机并行的能力,提升海量数据的处理速度,适合大数据量的分析。在某些场景中,查询计算量不是特别大,RDS没有分布式的开销,反而查询得更快。也有某些场景下,单机的RDS可以更好利用存储的索引来提升查询性能。

查询性能问题

  • Q:查询内存超限怎么办?

    A:AnalyticDB MySQL版中查询内存限制都是为了保证整个集群的稳定性,避免某些慢SQL查询导致集群崩溃。关于慢SQL查询排查分析,请参见慢查询的分类,重点关注峰值内存和扫描量。

    下表汇总了查询超限的错误码及对应异常和处理办法。
    ErrorCode 异常原因 处理办法
    CLUSTER_OUT_OF_MEMORY(32001) 集群当时内存消耗整体比较大,为了保持系统整体的稳定性,会选择断开一个内存使用特别大的查询连接,以免影响其他查询的正常运行。
    1. 建议限制查询的并发量。
    2. 在诊断与优化界面排查当前阶段的慢查询中有没有峰值内存和扫描量比较高的查询,并分析查询内存高的原因。
    EXCEEDED_MEMORY_LIMIT(32003) 当前查询的内存使用消耗超过内存限制。 建议结合SQL排查该Query消耗内存大的算子。
    OUT_OF_PHYSICAL_MEMORY_ERROR(33015) 当前Query运行时超过内部计算内存池限制。 可以排查出现问题的阶段,有没有峰值内存和扫描量比较高的查询,并分析查询内存高的原因。
  • Q:查询过程中报磁盘超出限制是什么原因,应该怎么处理?

    A:在弹性规格下,查询有可能会使用batch模式,查询会把查询的中间结果写入磁盘,这时候如果中间结果集较大,就有可能触发磁盘空间超出限制的情况。

    ErrorCode 异常原因 处理办法
    OUT_OF_SPILL_SPACE(32007) 当前落盘大小超过磁盘的限制,磁盘没有足够空间落盘。 首先需要分析SQL执行过程中落盘量大的原因,慢查询中重点关注峰值内存和扫描量。同时可以将batch_hash_partition_count(默认为32)参数值修改到一个较大的值,最大建议修改到64,如果太大会出现其他错误。
    EXCEEDED_SPILL_LIMIT(32006)
  • Q:查询突然变慢怎么处理?
    A:同一个SQL模板的查询变慢,可能有如下原因:
    • 相同条件下某些表的数据量增加导致处理的数据量增加,最终导致查询变慢。
    • 查询条件有变化,例如扫描的二级分区数增多,或者查询范围增加。
    • 系统压力增加。可能是写入量增加占用了较多系统资源,影响了查询性能,也可能是有Bad SQL的存在占用了较多系统资源。

    您可以结合实例运行报告页面的查询Pattern统计来查看不同的SQL模板在正常情况下的资源消耗,例如扫描量、内存、cputime等信息,以及在诊断优化页面的慢查询列表中根据资源消耗搜索占用资源较多的SQL等这些方法来定位。

  • Q:大内存查询和占用CPU较高的查询如何定位?

    A:更多详情,请参见慢查询的分类

  • Q:C系列和E系列性能哪个更优?

    A:推荐使用E系列。E系列采用计算存储分离的架构,可以比较灵活地搭配存储、计算资源,也支持分时弹性、资源组、batch query、数据冷热分层等特性。C系列是资源预留的模式,采用计算存储耦合的架构,对于毫秒级的查询能够有比较好的查询延迟体验。不同系列的差异,请参见产品系列