华为云用户手册

  • 不支持下推的函数 首先介绍函数的易变性。在 GaussDB 中共分三种形态: IMMUTABLE 表示该函数在给出同样的参数值时总是返回同样的结果。 STABLE 表示该函数不能修改数据库,对相同参数值,在同一次表扫描里,该函数的返回值不变,但是返回值可能在不同SQL语句之间变化。 VOLATILE 表示该函数值可以在一次表扫描内改变,因此不会做任何优化。 函数易变性可以查询pg_proc的provolatile字段获得,i代表IMMUTABLE,s代表STABLE,v代表VOLATILE。另外,在pg_proc中的proshippable字段,取值范围为t/f/NULL,这个字段与provolatile字段一起用于描述函数是否下推。 如果函数的provolatile属性为i,则无论proshippable的值是否为t,则函数始终可以下推。 如果函数的provolatile属性为s或v,则仅当proshippable的值为t时,函数可以下推。 random,exec_hadoop_sql,exec_on_extension如果出现CTE中,也不下推。因为这种场景下下推可能出现结果错误。 对于用户自定义函数,可以在创建函数的时候指定provolatile和proshippable属性的值,详细请参考CREATE FUNCTION语法。 对于函数不能下推的场景: 如果是系统函数,建议根据业务等价替换这个函数。 如果是自定义函数,建议分析客户业务场景,看函数的provolatile和proshippable属性定义是否正确。
  • 告警场景 目前支持对以下7种导致性能问题的场景上报告警。 多列/单列统计信息未收集 如果存在单列或者多列统计信息未收集,则上报相关告警。调优方法可以参考更新统计信息和统计信息调优。 需要特别注意的是,对于基于OBS外表的查询,如果未收集统计信息也会上报统计信息未收集的告警,但是由于OBS外表的analyze的性能比较差,因此,需要用户对这种场景下告警是否通过analyze收集统计信息,以获取更优的性能,和查询本身的复杂度做权衡。 告警信息示例: 整表的统计信息未收集: Statistic Not Collect: schema_test.t1 单列统计信息未收集: Statistic Not Collect: schema_test.t2(c1,c2) 多列统计信息未收集: Statistic Not Collect: schema_test.t3((c1,c2)) 单列和多列统计信息未收集: Statistic Not Collect: schema_test.t4(c1,c2) schema_test.t4((c1,c2)) SQL不下推 对于不下推的SQL,尽可能详细上报导致不下推的原因。调优方法可以参考案例语句下推调优。 对于函数导致的不下推,告警导致不下推的函数名信息; 对于不支持下推的语法,会告警对应语法不支持下推,例如:含有With Recursive,Distinct On,row表达式,返回值为record类型的,会告警相应语法不支持下推等等。 告警信息示例: SQL is not plan-shipping, reason : "With Recursive" can not be shipped" SQL is not plan-shipping, reason : "Function now() can not be shipped" SQL is not plan-shipping, reason : "Function string_agg() can not be shipped" HashJoin中大表做内表 如果在表连接过程中使用了HashJoin(可以在GS_WLM_SESSION_HISTORY视图的query_plan字段中查看到),且连接的内表行数是外表行数的10倍或以上;同时内表在每个DN上的平均行数大于10万行,且发生了下盘,则上报相关告警。调优方法可以参考使用Plan Hint进行调优。 告警信息示例: PlanNode[7] Large Table is INNER in HashJoin “Vector Hash Aggregate” 大表等值连接使用Nestloop 如果在表连接过程中使用了nestloop(可以在GS_WLM_SESSION_HISTORY视图的query_plan字段中查看到),并且两个表中较大表的行数平均每个DN上的行数大于10万行、表的连接中存在等值连接,则上报相关告警。调优方法可以参考使用Plan Hint进行调优。 告警信息示例: PlanNode[5] Large Table with Equal-Condition use Nestloop"Nested Loop" 大表Broadcast 如果在Broadcast算子中,平均每DN的行数大于10万行,则告警大表broadcast。调优方法可以参考使用Plan Hint进行调优。 告警信息示例: PlanNode[5] Large Table in Broadcast "Streaming(type: BROADCAST dop: 1/2)" 数据倾斜 某表在各DN上的分布,存在某DN上的行数是另一DN上行数的10倍或以上,且有DN中的行数大于10万行,则上报相关告警。调优方法可以参考案例数据倾斜调优。 告警信息示例: PlanNode[6] DataSkew:"Seq Scan", min_dn_tuples:0, max_dn_tuples:524288 估算不准 如果优化器的估算行数和实际行数中的较大值平均每DN行数大于10万行,并且估算行数和实际行数中较大值是较小值的10倍或以上,则上报相关告警。调优方法可以参考使用Plan Hint进行调优。 告警信息示例: PlanNode[5] Inaccurate Estimation-Rows: "Hash Join" A-Rows:0, E-Rows:52488
  • 规格约束 告警字符串长度上限为2048。如果告警信息超过这个长度(例如存在大量未收集统计信息的超长表名,列名等信息)则不告警,只上报warning: WARNING, "Planner issue report is truncated, the rest of planner issues will be skipped" 如果query存在limit节点(即查询语句中包含limit),则不会上报limit节点以下的Operator级别的告警。 对于“数据倾斜”和“估算不准”两种类型告警,在某一个plan树结构下,只上报下层节点的告警,上层节点不再重复告警。这主要是因为这两种类型的告警可能是因为底层触发上层的。例如,如果在scan节点已经存在数据倾斜,那么在上层的hashagg等其他算子很可能也出现数据倾斜。
  • 统计信息调优介绍 GaussDB是基于代价估算生成的最优执行计划。优化器需要根据analyze收集的统计信息进行行数估算和代价估算,因此统计信息对优化器行数估算和代价估算起着至关重要的作用。通过analyze收集全局统计信息,主要包括:pg_class表中的relpages和reltuples;pg_statistic表中的stadistinct、stanullfrac、stanumbersN、stavaluesN、histogram_bounds等。
  • 选择数据类型 高效数据类型,主要包括以下三方面: 尽量使用执行效率比较高的数据类型 一般来说整型数据运算(包括=、>、<、≧、≦、≠等常规的比较运算,以及group by)的效率比字符串、浮点数要高。比如某客户场景中对列存表进行点查询,filter条件在一个numeric列上,执行时间为10+s;修改numeric为int类型之后,执行时间缩短为1.8s左右。 尽量使用短字段的数据类型 长度较短的数据类型不仅可以减小数据文件的大小,提升IO性能;同时也可以减小相关计算时的内存消耗,提升计算性能。比如对于整型数据,如果可以用smallint就尽量不用int,如果可以用int就尽量不用bigint。 使用一致的数据类型 表关联列尽量使用相同的数据类型。如果表关联列数据类型不同,数据库必须动态地转化为相同的数据类型进行比较,这种转换会带来一定的性能开销。 父主题: 审视和修改表定义
  • 使用分区表 分区表是把逻辑上的一张表根据某种方案分成几张物理块进行存储。这张逻辑上的表称之为分区表,物理块称之为分区。分区表是一张逻辑表,不存储数据,数据实际是存储在分区上的。分区表和普通表相比具有以下优点: 改善查询性能:对分区对象的查询可以仅搜索自己关心的分区,提高检索效率。 增强可用性:如果分区表的某个分区出现故障,表在其他分区的数据仍然可用。 方便维护:如果分区表的某个分区出现故障,需要修复数据,只修复该分区即可。 GaussDB支持的分区表为范围分区表。 范围分区表:将数据基于范围映射到每一个分区。这个范围是由创建分区表时指定的分区键决定的。分区键经常采用日期,例如将销售数据按照月份进行分区。 父主题: 审视和修改表定义
  • 选择存储模型 进行数据库设计时,表设计上的一些关键项将严重影响后续整库的查询性能。表设计对数据存储也有影响:好的表设计能够减少I/O操作及最小化内存使用,进而提升查询性能。 表的存储模型选择是表定义的第一步。客户业务属性是表的存储模型的决定性因素,依据下面表格选择适合当前业务的存储模型。 存储模型 适用场景 行存 点查询(返回记录少,基于索引的简单查询)。 增删改比较多的场景。 列存 统计分析类查询 (group , join多的场景)。 父主题: 审视和修改表定义
  • 支持的事件列表 表1 云数据库GaussDB 事件来源 事件名称 事件ID 事件级别 事件说明 处理建议 事件影响 GaussDB 进程状态告警 ProcessStatusAlarm 重要 GaussDB关键进程退出,包括:CMS/CMA、ETCD、GTM、CN、DN。 等待进程自动恢复或者自动主备切换,观察业务是否恢复。如果业务未恢复,联系SRE。 主机进程故障,在主机上进行的业务将中断回滚。备机进程故障不影响业务。 组件状态告警 ComponentStatusAlarm 重要 GaussDB关键组件无响应,包括:CMA、ETCD、GTM、CN、DN。 等待进程自动恢复或者自动主备切换,观察业务是否恢复。如果业务未恢复,联系SRE。 主机进程无响应,在主机上进行的业务将无响应。备机进程故障不影响业务。 集群状态告警 ClusterStatusAlarm 重要 集群状态异常,包括: 集群只读、ETCD多数派故障、集群分布不均衡。 联系SRE。 集群只读: 业务只读。 ETCD多数派故障:集群不可用。 集群分布不均衡:集群性能/可靠性降低。 硬件资源告警 HardwareResourceAlarm 重要 集群中出现严重的硬件故障,包括:磁盘损坏、GTM网络通信故障。 联系SRE。 业务部分/全部受损。 状态转换告警 StateTransitionAlarm 重要 集群出现如下重要事件:DN build/build失败、DN强切、DN主备切换/failover、GTM主备切换/failover。 等待自动恢复,观察业务是否恢复。如果业务未恢复,联系SRE。 部分业务受损。 其他异常告警 OtherAbnormalAlarm 重要 磁盘使用阈值告警等。 关注业务变化,及时计划扩容。 超过使用阈值,将无法扩容。 实例运行状态异常 TaurusInstanceRunningStatusAbnormal 重要 由于灾难或者物理机故障导致实例故障时,会上报该事件,属于关键告警事件。 提交工单。 可能导致数据库服务不可用。 实例运行状态异常已恢复 TaurusInstanceRunningStatusRecovered 重要 针对灾难性的故障,GaussDB有高可用工具会自动进行恢复或者手动恢复,执行完成后会上报该事件。 不需要处理。 无 节点运行状态异常 TaurusNodeRunningStatusAbnormal 重要 由于灾难或者物理机故障导致数据库节点故障时,会上报该事件,属于关键告警事件。 检查数据库服务是否可以正常使用,并提交工单。 可能导致数据库服务不可用。 节点运行状态异常已恢复 TaurusNodeRunningStatusRecovered 重要 针对灾难性的故障,GaussDB有高可用工具会自动进行恢复或者手动恢复,执行完成后会上报该事件。 不需要处理。 无 创建实例业务失败 GaussDBV5CreateInstanceFailed 重要 创建实例失败产生的事件,一般是配额大小不足,底层资源耗尽导致。 先释放不再使用的实例再尝试重新发放,或者提交工单调整配额上限。 无法创建数据库实例。 添加节点失败 GaussDBV5ExpandClusterFailed 重要 一般是由于底层资源不足等原因导致。 提交工单让运维在后台协调资源,删除添加失败的节点,重新尝试添加新节点。 无 存储扩容失败 GaussDBV5EnlargeVolumeFailed 重要 一般是由于底层资源不足等原因导致。 提交工单让运维在后台协调资源再重试扩容操作。 如果磁盘满,会导致业务中断。 重启失败 GaussDBV5RestartInstanceFailed 重要 一般是由于网络问题等原因导致 重试重启操作或提交工单让运维处理。 可能导致数据库服务不可用。 全量备份失败 GaussDBV5FullBackupFailed 重要 一般是备份文件导出失败或上传失败等原因导致。 提交工单让运维处理。 无法备份数据。 差量备份失败 GaussDBV5DifferentialBackupFailed 重要 一般是备份文件导出失败或上传失败等原因导致。 提交工单让运维处理。 无法备份数据。 删除备份失败 GaussDBV5DeleteBackupFailed 重要 无需实现。 - - 绑定EIP失败 GaussDBV5BindEIPFailed 重要 弹性公网IP已被占用或IP资源等原因导致。 提交工单让运维处理。 导致实例无法使用公网链接或访问 解绑EIP失败 GaussDBV5UnbindEIPFailed 重要 网络故障或公网EIP服务故障等原因导致。 重新解绑Ip或提交工单让运维处理。 可能导致IP资源残留 参数组应用失败 GaussDBV5ApplyParamFailed 重要 一般是由于修改参数组命令超时导致。 重新尝试修改参数组操作。 无 参数修改失败 GaussDBV5UpdateInstanceParamGroupFailed 重要 一般是由于修改参数组命令超时导致。 重新尝试修改参数组操作。 无 备份恢复失败 GaussDBV5RestoreFromBcakupFailed 重要 一般是由底层资源不足或备份文件下载失败等原因导致 提交工单。 可能导致在恢复失败期间数据库服务不可用 父主题: 监控与告警
  • 审视和修改表定义概述 在分布式框架下,数据分布在各个DN上。一个或者几个DN的数据存在一块物理存储设备上,好的表定义至少需要达到以下几个目标: 表数据均匀分布在各个DN上,以防止单个DN对应的存储设备空间不足造成集群有效容量下降。选择合适分布列,避免数据分布倾斜可以实现该点。 表Scan压力均匀分散在各个DN上,以避免单DN的Scan压力过大,形成Scan的单节点瓶颈。分布列不选择基表上等值filter中的列可以实现该点。 减少扫描数据数据量。通过分区的剪枝机制可以实现该点。 尽量极少随机IO。通过聚簇/局部聚簇可以实现该点。 尽量避免数据shuffle,减小网络压力。通过选择join-condition或者group by列为分布列可以更好的实现这点。 从上述描述来看表定义中最重要的一点是分布列的选择。创建表定义一般遵循图1所示流程。表定义在数据库设计阶段创建,在SQL调优过程中进行审视和修改。 图1 表定义流程 父主题: 审视和修改表定义
  • 选择分布方式 复制表(Replication)方式将表中的全量数据在集群的每一个DN实例上保留一份。主要适用于记录集较小的表。这种存储方式的优点是每个DN上都有该表的全量数据,在join操作中可以避免数据重分布操作,从而减小网络开销,同时减少了plan segment(每个plan segment都会起对应的线程);缺点是每个DN都保留了表的完整数据,造成数据的冗余。一般情况下只有较小的维度表才会定义为Replication表。 哈希(Hash)表将表中某一个或几个字段进行hash运算后,生成对应的hash值,根据DN实例与哈希值的映射关系获得该元组的目标存储位置。对于Hash分布表,在读/写数据时可以利用各个节点的IO资源,大大提升表的读/写速度。一般情况下大表定义为Hash表。 范围(Range)和列表(List)分布是由用户自定义的分布策略,根据分布列的取值落入满足一定范围或者具体值的对应目标DN,这两种分布方式便于用户灵活地进行数据管理,但对用户本身的数据抽象能力有一定的要求。 策略 描述 适用场景 Hash 表数据通过hash方式散列到集群中的所有DN实例上。 数据量较大的事实表。 Replication 集群中每一个DN实例上都有一份全量表数据。 小表、维度表。 Range 表数据对指定列按照范围进行映射,分布到对应DN。 用户需要自定义分布规则的场景。 List 表数据对指定列按照具体值进行映射,分布到对应DN。 用户需要自定义分布规则的场景。 如图1所示,复制表如图中的表T1,哈希表如图中的表T2。 图1 复制表和哈希表 父主题: 审视和修改表定义
  • 检查隐式转换的性能问题 在某些场景下,数据类型的隐式转换可能会导致潜在的性能问题。请看如下的场景: SET enable_fast_query_shipping = off; CREATE TABLE t1(c1 VARCHAR, c2 VARCHAR); CREATE INDEX on t1(c1); EXPLAIN verbose SELECT * FROM t1 WHERE c1 = 10; 上述查询的执行计划如下: c1的数据类型是varchar,当查询的过滤条件为c1 = 10时,优化器默认将c1隐式转换为bigint类型,导致两个后果: 不能进行DN裁剪,计划下发到所有DN上执行。 计划中不能使用Index Scan方式扫描数据。 这会引起潜在的性能问题。 当知道了问题原因后,可以做针对性的SQL改写。对于上面的场景,只要将过滤条件中的常量显示转换为varchar类型,结果如下: EXPLAIN verbose SELECT * FROM t1 WHERE c1 = 10::varchar; 为了提前识别隐式类型转换可能带来的性能影响,GaussDB提供了一个guc option:check_implicit_conversions。打开该参数后,对于查询中出现的隐式类型转换的索引列,在路径生成阶段进行检查,如果发现索引列没有生成候选的索引扫描路径,则会通过报错的形式提示给用户。举例如下: SET check_implicit_conversions = on; SELECT * FROM t1 WHERE c1 = 10; ERROR: There is no optional index path for index column: "t1"."c1". Please check for potential performance problem. 参数check_implicit_conversions只用于检查隐式类型转换引起的潜在性能问题,在正式生产环境中请关闭该参数(该参数默认关闭)。 在将check_implicit_conversions打开时,必须同时关闭enable_fast_query_shipping参数,否则由于后一个参数的作用,无法查看对隐式类型转换修复的结果。 一个表的候选路径可能包括seq scan和index scan等多个可能的数据扫描方式,最终执行计划使用的表扫描方式是由执行计划的代价来决定的,因此即使生成了索引扫描的候选路径,也可能生成的最终执行计划中使用其它扫描方式。 父主题: SQL调优指南
  • 操作步骤 收集SQL中涉及到的所有表的统计信息。在数据库中,统计信息是规划器生成计划的源数据。没有收集统计信息或者统计信息陈旧往往会造成执行计划严重劣化,从而导致性能问题。从经验数据来看,10%左右性能问题是因为没有收集统计信息。具体请参见更新统计信息。 通过查看执行计划来查找原因。如果SQL长时间运行未结束,通过EXPLAIN命令查看执行计划,进行初步定位。如果SQL可以运行出来,则推荐使用EXPLAIN ANALYZE或EXPLAIN PERFORMANCE查看执行计划及实际运行情况,以便更准确地定位问题原因。有关执行计划的详细介绍请参见SQL执行计划介绍。 审视和修改表定义。 针对EXPLAIN或EXPLAIN PERFORMANCE信息,定位SQL慢的具体原因以及改进措施,具体参见典型SQL调优点。 通常情况下,有些SQL语句可以通过查询重写转换成等价的,或特定场景下等价的语句。重写后的语句比原语句更简单,且可以简化某些执行步骤达到提升性能的目的。查询重写方法在各个数据库中基本是通用的。经验总结:SQL语句改写规则介绍了几种常用的通过改写SQL进行调优的方法。
  • 选择分布列 Hash分布表的分布列选取至关重要,需要满足以下原则: 列值应比较离散,以便数据能够均匀分布到各个DN。例如,考虑选择表的主键为分布列,如在人员信息表中选择身份证号码为分布列。 在满足第一条原则的情况下尽量不要选取存在常量filter的列。例如,表dwcjk相关的部分查询中出现dwcjk的列zqdh存在常量的约束(例如zqdh=’000001’),那么就应当尽量不用zqdh做分布列。 在满足前两条原则的情况,考虑选择查询中的连接条件为分布列,以便Join任务能够下推到DN中执行,且减少DN之间的通信数据量。 对于Hash分表策略,如果分布列选择不当,可能导致数据倾斜,查询时出现部分DN的I/O短板,从而影响整体查询性能。因此在采用Hash分表策略之后需对表的数据进行数据倾斜性检查,以确保数据在各个DN上是均匀分布的。可以使用以下SQL检查数据倾斜性 select xc_node_id, count(1) from tablename group by xc_node_id order by xc_node_id desc; 其中xc_node_id对应DN,一般来说,不同DN的数据量相差5%以上即可视为倾斜,如果相差10%以上就必须要调整分布列。 GaussDB支持多分布列特性,可以更好地满足数据分布的均匀性要求。 父主题: 审视和修改表定义
  • SQL调优指南 SQL调优的唯一目的是“资源利用最大化”,即CPU、内存、磁盘IO、网络IO四种资源利用最大化。所有调优手段都是围绕资源使用开展的。所谓资源利用最大化是指SQL语句尽量高效,节省资源开销,以最小的代价实现最大的效益。比如做典型点查询的时候,可以用seqscan+filter(即读取每一条元组和点查询条件进行匹配)实现,也可以通过indexscan实现,显然indexscan可以以更小的代价实现相同的效果。根据硬件资源和客户的业务特征确定合理的集群部署方案和表定义是数据库在多数情况下满足性能要求的基础。 Query执行流程 SQL执行计划介绍 调优流程 更新统计信息 审视和修改表定义 典型SQL调优点 经验总结:SQL语句改写规则 SQL调优关键参数调整 使用Plan Hint进行调优 检查隐式转换的性能问题 父主题: 性能调优
  • 执行计划 以如下SQL语句为例: select cjxh, count(1) from dwcjk group by cjxh; 执行EXPLAIN的输出为: 执行计划字段解读(横向): id:执行算子节点编号。 operation:具体的执行节点算子名称。 Vector前缀的算子是指向量化执行引擎算子,一般出现含有列存表的Query中。 Streaming是一个特殊的算子,它实现了分布式架构的核心数据shuffle功能,Streaming共有三种形态,分别对应了分布式结构下不同的数据shuffle功能: Streaming (type: GATHER):作用是coordinator从DN收集数据。 Streaming(type: REDISTRIBUTE):作用是DN根据选定的列把数据重分布到所有的DN。 Streaming(type: BROADCAST):作用是把当前DN的数据广播给其他所有的DN E-rows:每个算子估算的输出行数。 E-memory:DN上每个算子估算的内存使用量,只有DN上执行的算子会显示。某些场景会在估算的内存使用量后使用括号显示该算子在内存资源充足下可以自动扩展的内存上限。 E-width:每个算子输出元组的估算宽度。 E-costs:每个算子估算的执行代价。 E-costs是优化器根据成本参数定义的单位来衡量的,习惯上以磁盘页面抓取为1个单位, 其它开销参数将参照它来设置。 每个节点的开销(E-costs值)包括它的所有子节点的开销。 开销只反映了优化器关心的东西,并没有把结果行传递给客户端的时间考虑进去。虽然这个时间可能在实际的总时间里占据相当重要的分量,但是被优化器忽略了,因为它无法通过修改规划来改变。 执行计划层级解读(纵向): 第一层: CS tore Scan on dwcjk 表扫描算子,用CStore Scan的方式扫描表dwcjk。这一层的作用是把表dwcjk的数据从buffer或者磁盘上读上来输送给上层节点参与计算。 第二层:Vector Hash Aggregate 聚合算子,作用是把下层计算输送上来的算子做聚合操作(group by)。 第三层:Vector Streaming (type: GATHER) Shuffle算子,此处GATHER类型的Shuffle算子作用是把数据从DN汇聚到CN。 第四层:Row Adapter 存储格式转化算子,主要作用是把内存中列式格式数据转为行式数据,以便客户端展示。 需要注意的是最顶层算子为Data Node Scan时,需要设置enable_fast_query_shipping为off才能看到具体的执行计划,如下面这个计划: postgres=# explain select cjxh, count(1) from dwcjk group by cjxh; QUERY PLAN -------------------------------------------------- Data Node Scan (cost=0.00..0.00 rows=0 width=0) Node/s: All datanodes (2 rows) 设置enable_fast_query_shipping参数之后,执行计划显示如下: 执行计划中的关键字说明: 表访问方式 Seq Scan 全表顺序扫描。 Index Scan 优化器决定使用两步的规划:最底层的规划节点访问一个索引,找出匹配索引条件的行的位置,然后上层规划节点真实地从表中抓取出那些行。独立地抓取数据行比顺序地读取它们的开销高很多,但是因为并非所有表的页面都被访问了,这么做实际上仍然比一次顺序扫描开销要少。使用两层规划的原因是,上层规划节点在读取索引标识出来的行位置之前,会先将它们按照物理位置排序,这样可以最小化独立抓取的开销。 如果在WHERE里面使用的好几个字段上都有索引,那么优化器可能会使用索引的AND或OR的组合。但是这么做要求访问两个索引,因此与只使用一个索引,而把另外一个条件只当作过滤器相比,这个方法未必是更优。 索引扫描可以分为以下几类,不同类型之间的差异在于索引的排序机制。 Bitmap Index Scan 使用位图索引抓取数据页。 Index Scan using index_name 使用简单索引搜索,该方式表的数据行是以索引顺序抓取的,这样就令读取它们的开销更大,但是这里的行少得可怜,因此对行位置的额外排序并不值得。最常见的就是看到这种规划类型只抓取一行,以及那些要求ORDER BY条件匹配索引顺序的查询。因为那时候没有多余的排序步骤是必要的以满足ORDER BY。 表连接方式 Nested Loop 嵌套循环,适用于被连接的数据子集较小的查询。在嵌套循环中,外表驱动内表,外表返回的每一行都要在内表中检索找到它匹配的行,因此整个查询返回的结果集不能太大(不能大于10000),要把返回子集较小的表作为外表,而且在内表的连接字段上建议要有索引。 (Sonic) Hash Join 哈希连接,适用于数据量大的表的连接方式。优化器使用两个表中较小的表,利用连接键在内存中建立hash表,然后扫描较大的表并探测散列,找到与散列匹配的行。Sonic和非Sonic的Hash Join的区别在于所使用hash表结构不同,不影响执行的结果集。 Merge Join 归并连接,通常情况下执行性能差于哈希连接。如果源数据已经被排序过,在执行融合连接时,并不需要再排序,此时融合连接的性能优于哈希连接。 运算符 sort 对结果集进行排序。 filter EXPLAIN输出显示WHERE子句当作一个"filter"条件附属于顺序扫描计划节点。这意味着规划节点为它扫描的每一行检查该条件,并且只输出符合条件的行。预计的输出行数降低了,因为有WHERE子句。不过,扫描仍将必须访问所有 10000 行,因此开销没有降低;实际上它还增加了一些(确切的说,通过10000 * cpu_operator_cost)以反映检查WHERE条件的额外CPU时间。 LIMIT LIMIT限定了执行结果的输出记录数。如果增加了LIMIT,那么不是所有的行都会被检索到。
  • 执行信息 在SQL调优过程中经常需要执行EXPLAIN ANALYZE或EXPLAIN PERFORMANCE查看SQL语句实际执行信息,通过对比实际执行与优化器的估算之间的差别来为优化提供依据。EXPLAIN PERFORMANCE相对于EXPLAIN ANALYZE增加了每个DN上的执行信息。 以如下SQL语句为例: select count(1) from tb1; 执行EXPLAIN PERFORMANCE输出为: 图中显示执行信息分为以下7个部分 以表格的形式将计划显示出来,包含有11个字段,分别是:id、operation、A-time、A-rows、E-rows、E-distinct、Peak Memory、E-memory、A-width、E-width和E-costs。其中计划类字段(id、operation以及E开头字段)的含义与执行EXPLAIN时的含义一致,详见执行计划小节中的说明。A-time、A-rows、E-distinct、Peak Memory、A-width的含义说明如下: A-time:当前算子执行完成时间,一般DN上执行的算子的A-time是由[]括起来的两个值,分别表示此算子在所有DN上完成的最短时间和最长时间。 A-rows:表示当前算子的实际输出元组数。 E-distinct:表示hashjoin算子的distinct估计值。 Peak Memory:此算子在每个DN上执行时使用的内存峰值。 A-width:表示当前算子每行元组的实际宽度,仅对于重内存使用算子会显示,包括:(Vec)HashJoin、(Vec)HashAgg、(Vec) HashSetOp、(Vec)Sort、(Vec)Materialize算子等,其中(Vec)HashJoin计算的宽度是其右子树算子的宽度,会显示在其右子树上。 Predicate Information (identified by plan id): 这一部分主要显示的是静态信息,即在整个计划执行过程中不会变的信息,主要是一些join条件和一些filter信息。 Memory Information (identified by plan id): 这一部分显示的是整个计划中会将内存的使用情况打印出来的算子的内存使用信息,主要是Hash、Sort算子,包括算子峰值内存(peak memory),控制内存(control memory),估算内存使用(operator memory),执行时实际宽度(width),内存使用自动扩展次数(auto spread num),是否提前下盘(early spilled),以及下盘信息,包括重复下盘次数(spill Time(s)),内外表下盘分区数(inner/outer partition spill num),下盘文件数(temp file num),下盘数据量及最小和最大分区的下盘数据量(written disk IO [min, max] )。 Targetlist Information (identified by plan id) 这一部分显示的是每一个算子输出的目标列。 DataNode Information (identified by plan id): 这一部分会将各个算子的执行时间、CPU、buffer的使用情况全部打印出来。 User Define Profiling 这一部分显示的是CN和DN、DN和DN建连的时间,以及存储层的一些执行信息。 ====== Query Summary =====: 这一部分主要打印总的执行时间和网络流量,包括了各个DN上初始化和结束阶段的最大最小执行时间、CN上的初始化、执行、结束阶段的时间,以及当前语句执行时系统可用内存、语句估算内存等信息。 A-rows和E-rows的差异体现了优化器估算和实际执行的偏差度。一般来说,偏差越大优化器生成的计划越不可信,人工干预调优的必要性越大。 A-time中的两个值偏差越大,表明此算子的计算偏斜(在不同DN上执行时间差异)越大,人工干预调优的必要性越大。 Max Query Peak Memory经常用来估算SQL语句耗费内存,也被用来作为SQL语句调优时运行态内存参数设置的重要依据。一般会以EXPLAIN ANALYZE或EXPLAIN PERFORMANCE的输出作为进一步调优的输入。
  • 执行计划显示格式 GaussDB对执行计划提供了normal、pretty、summary、run四种显示格式: normal:代表使用默认的打印格式。图1中即为此显示格式。 pretty:代表使用GaussDB改进后的新显示格式。新的格式层次清晰,计划包含了plan node id,性能分析简单直接。如图2。 summary:是在pretty的基础上增加了对打印信息的分析。 run:在summary的基础上,将统计的信息输出到csv格式的文件中,以便于进一步分析。 图2 pretty格式执行计划示例 通过设置GUC参数explain_perf_mode,可以显示不同格式的执行计划。下文的用例默认显示pretty格式。
  • 背景信息 ANALYZE语句可收集与数据库中表内容相关的统计信息,统计结果存储在系统表PG_STATISTIC中。查询优化器会使用这些统计数据,以生成最有效的执行计划。 建议在执行了大批量插入/删除操作后,例行对表或全库执行ANALYZE语句更新统计信息。目前默认收集统计信息的采样比例是30000行(即:guc参数default_statistics_target默认设置为100),如果表的总行数超过一定行数(大于1600000),建议设置guc参数default_statistics_target为-2,即按2%收集样本估算统计信息。 对于在批处理脚本或者存储过程中生成的中间表,也需要在完成数据生成之后显式的调用ANALYZE。 对于表中多个列有相关性且查询中有同时基于这些列的条件或分组操作的情况,可尝试收集多列统计信息,以便查询优化器可以更准确地估算行数,并生成更有效的执行计划。
  • 操作步骤 使用以下命令更新某个表或者整个database的统计信息。 ANALYZE tablename; --更新单个表的统计信息 ANALYZE; --更新全库的统计信息 使用以下命令进行多列统计信息相关操作。 ANALYZE tablename ((column_1, column_2)); --收集tablename表的column_1、column_2列的多列统计信息 ALTER TABLE tablename ADD STATIS TICS ((column_1, column_2)); --添加tablename表的column_1、column_2列的多列统计信息声明 ANALYZE tablename; --收集单列统计信息,并收集已声明的多列统计信息 ALTER TABLE tablename DELETE STATISTICS ((column_1, column_2)); --删除tablename表的column_1、column_2列的多列统计信息或其声明 在使用ALTER TABLE tablename ADD STATISTICS语句添加了多列统计信息声明后,系统并不会立刻收集多列统计信息,而是在下次对该表或全库进行ANALYZE时,进行多列统计信息的收集。 如果想直接收集多列统计信息,请使用ANALYZE命令进行收集。 使用EXPLAIN查看各SQL的执行计划时,如果发现某个表SEQ SCAN的输出中rows=10,rows=10是系统给的默认值,有可能该表没有进行ANALYZE,需要对该表执行ANALYZE。
  • 调优手段之GUC参数 查询优化的主要目的是为查询语句选择高效的执行方式。 如下SQL语句: select count(1) from customer inner join store_sales on (ss_customer_sk = c_customer_sk); 在执行customer inner join store_sales的时候,GaussDB支持Nested Loop、Merge Join和Hash Join三种不同的Join方式。优化器会根据表customer和表store_sales的统计信息估算结果集的大小以及每种join方式的执行代价,然后对比选出执行代价最小的执行计划。 正如前面所说,执行代价计算都是基于一定的模型和统计信息进行估算,当因为某些原因代价估算不能反映真实的cost的时候,就需要通过guc参数设置的方式让执行计划倾向更优规划。
  • 性能因素 多个性能因素会影响数据库性能,了解这些因素可以帮助定位和分析性能问题。 系统资源 数据库性能在很大程度上依赖于磁盘的I/O和内存使用情况。为了准确设置性能指标,用户需要了解集群部署硬件的基本性能。CPU,硬盘,磁盘控制器,内存和网络接口等这些硬件性能将显著影响数据库的运行速度。 负载 负载等于数据库系统的需求总量,它会随着时间变化。总体负载包含用户查询,应用程序,并行作业,事务以及数据库随时传递的系统命令。比如:多用户在执行多个查询时会提高负载。负载会显著地影响数据库的性能。了解工作负载高峰期可以帮助用户更合理地利用系统资源,更有效地完成系统任务。 吞吐量 使用系统的吞吐量来定义处理数据的整体能力。数据库的吞吐量以每秒的查询次数、每秒的处理事务数量或平均响应时间来测量。数据库的处理能力与底层系统(磁盘I/O,CPU速度,存储器带宽等)有密切的关系,所以当设置数据库吞吐量目标时,需要提前了解硬件的性能。 竞争 竞争是指两组或多组负载组件尝试使用冲突的方式使用系统的情况。比如,多条查询视图同一时间更新相同的数据,或者多个大量的负载争夺系统资源。随着竞争的增加,吞吐量下降。 优化 数据库优化可以影响到整个系统的性能。在执行SQL制定、数据库配置参数、表设计、数据分布等操作时,启用数据库查询优化器打造最有效的执行计划。
  • 调优范围确定 性能调优主要通过查看集群各节点的CPU、内存、I/O和网络这些硬件资源的使用情况,确认这些资源是否已被充分利用,是否存在瓶颈点,然后针对性调优。 如果某个资源已达瓶颈,则: 通过查询最耗时的SQL语句、跑不出来的SQL语句,找出耗资源的SQL,进行SQL调优指南。 如果所有资源均未达瓶颈,则表明性能仍有提升潜力。可以查询最耗时的SQL语句,或者跑不出来的SQL语句,进行针对性的SQL调优指南。
  • 操作步骤 使用DAS或者gsql连接实例。 查看阻塞的查询语句及阻塞查询的表、模式信息。 SELECT w.query as waiting_query, w.pid as w_pid, w.usename as w_user, l.query as locking_query, l.pid as l_pid, l.usename as l_user, t.schemaname || '.' || t.relname as tablename from pg_stat_activity w join pg_locks l1 on w.pid = l1.pid and not l1.granted join pg_locks l2 on l1.relation = l2.relation and l2.granted join pg_stat_activity l on l2.pid = l.pid join pg_stat_user_tables t on l1.relation = t.relid where w.waiting; 该查询返回线程ID、用户信息、查询状态,以及导致阻塞的表、模式信息。 使用如下命令结束相应的会话。 SELECT PG_TERMINATE_BACKEND(139834762094352); 其中,139834762094352为线程ID。 显示类似如下信息,表示结束会话成功。 PG_TERMINATE_BACKEND ---------------------- t (1 row) 显示类似如下信息,表示用户正在尝试结束当前会话。 FATAL: terminating connection due to administrator command FATAL: terminating connection due to administrator command gsql客户端使用PG_TERMINATE_BACKEND函数结束当前正在执行会话的后台线程时,如果当前的用户是初始用户,客户端不会退出而是自动重连,即还会返回“The connection to the server was lost. Attempting reset: Succeeded.”;否则客户端会重连失败,即返回“The connection to the server was lost. Attempting reset: Failed.”。这是因为只有初始用户可以免密登录,普遍用户不能免密登录,从而重连失败。 对于使用PG_TERMINATE_BACKEND函数结束非活跃的后台线程时。如果打开了线程池,此时空闲的会话没有线程ID,无法结束会话。非线程池模式下,结束的会话不会自动重连。
  • 调优手段之统计信息 GaussDB优化器是典型的基于代价的优化 (Cost-Based Optimization,简称CBO)。在这种优化器模型下,数据库根据表的元组数、字段宽度、NULL记录比率、distinct值、MCV值、HB值等表的特征值,以及一定的代价计算模型,计算出每一个执行步骤的不同执行方式的输出元组数和执行代价(cost),进而选出整体执行代价最小/首元组返回代价最小的执行方式进行执行。这些特征值就是统计信息。从上面描述可以看出统计信息是查询优化的核心输入,准确的统计信息将帮助规划器选择最合适的查询规划,一般来说通过analyze语法收集整个表或者表的若干个字段的统计信息,周期性地运行ANALYZE,或者在对表的大部分内容做了更改之后马上运行它是个好习惯。
  • 使用须知 当前只提供主备版实例, 并且数据库引擎需要为2.1.0及以上版本。 访问日志提供了实例所请求的所有详细日志,日志存在LTS 云日志 服务中。 配置完成后,日志不会立即上传,需要等待10分钟左右才可以在LTS服务上查询审计日志。 控制审计日志的总开关参考参数audit_enabled。 控制审计日志的具体参数配置参考审计项。 配置完成后,会产生一定费用,费用情况请参考LTS的 定价 详情。 在您进行LTS审计日志配置后,会默认上传当前实例的所有审计策略到LTS服务。
  • 查询 track_stmt_session_slot 作用:设置一个session缓存的最大的全量/慢SQL的数量。 影响:缓存的SQL定期会被写入到系统表,如果业务量很大,超过这个数量语句执行将不会被跟踪,直到落盘线程将缓存语句落盘,留出空闲的空间,但不影响SQL的执行。 effective_cache_size 作用:设置节点优化器在一次单一的查询中可用的磁盘缓冲区的有效大小。设置这个参数,还要考虑的共享缓冲区以及内核的磁盘缓冲区。另外,还要考虑预计的在不同表之间的并发查询数目,因为它们将共享可用的空间。这个参数对分配的共享内存大小没有影响,它也不会使用内核磁盘缓冲,它只用于估算。数值是用磁盘页来计算的,通常每个页面是8192字节。 取值范围:整型,1~INT_MAX,单位为8KB。 影响:比默认值高的数值可能会导致使用索引扫描,更低的数值可能会导致选择顺序扫描。 enable_stream_operator 控制优化器对stream的使用。当该参数关闭时,可能会有大量关于计划不能下推的日志记录到日志文件中。 log_min_duration_statement 作用:当某条语句的持续时间大于或者等于特定的毫秒数时,记录每条完成语句的持续时间。设置log_min_duration_statement可以很方便地跟踪需要优化的查询语句。对于使用扩展查询协议的客户端,语法分析、绑定、执行每一步所花时间被独立记录。 影响:设置过低的阈值可能影响负载吞吐,-1表示关闭此功能。
  • 连接与认证 session_timeout 表明与服务器建立连接后,不进行任何操作一定时间后超时的限制,0表示关闭超时设置。 failed_login_attempts 设置密码错误次数上限,输入密码错误的次数达到该参数所设置的值时,账户将会被自动锁定,配置为0时表示不限制密码输入错误的次数。 password_effect_time 设置帐户密码的有效时间,0表示不开启有效期限制功能。 password_lock_time 设置账户被锁定后的自动解锁时间,单位为天。
  • 自定义策略样例 示例1:授权用户创建GaussDB实例 { "Version": "1.1", "Statement": [{"Effect": "Allow","Action": ["gaussdb:instance:create"]}]} 示例2:拒绝用户删除GaussDB实例 拒绝策略需要同时配合其他策略使用,否则没有实际作用。用户被授予的策略中,一个授权项的作用如果同时存在Allow和Deny,则遵循Deny优先。 如果您给用户授予GaussDB FullAccess的系统策略,但不希望用户拥有GaussDB FullAccess中定义的删除GaussDB实例,您可以创建一条拒绝删除云服务的自定义策略,然后同时将GaussDB FullAccess和拒绝策略授予用户,根据Deny优先原则,则用户可以对GaussDB实例执行除了删除GaussDB实例外的所有操作。拒绝策略示例如下: {"Version": "1.1","Statement": [{"Action": ["gaussdb:instance:delete"],"Effect": "Deny"}]}
  • 注意事项 默认不支持将规格参数变小,如需要将规格参数变小,您可以联系华为云客服,由华为云工程师给出分析评估后进行处理。 基础版不支持规格变更。 规格变更前,须确保实例状态正常。实例异常,节点异常,磁盘满均不允许进行规格变更。 高可用(1主2备)部署形态下,规格变更过程中会进行主备倒换,主备倒换过程中会有1min左右的业务中断。 单副本的部署形态下,规格变更过程中会进行中断重启,中断重启过程中会有5~10min的业务中断。 修改CPU|内存后,将会重启数据库实例。请选择业务低峰期,避免业务异常中断。重启后实例会自动释放内存中的缓存,请在业务低峰期进行重启,避免对高峰期业务造成影响。
  • 支持审计的关键操作列表 通过 云审计 服务,您可以记录与GaussDB实例相关的操作事件,便于日后的查询、审计和回溯。 表1 云审计服务支持的操作列表 操作名称 资源类型 事件名称 创建实例、恢复到新实例 instance createInstance 删除实例 instance deleteInstance 数据库实例规格变更 instance resizeFlavor 实例版本升级 instance upgradeVersion 密码重置 instance resetPassword 实例重启 instance instanceRestart 绑定公共IP instance setOrResetPublicIP 解绑公共IP instance setOrResetPublicIP 修改资源标签 instance modifyTag 删除资源标签 instance deleteTag 添加资源标签 instance createTag 重命名实例 instance instanceRename 实例扩容 instance instanceAction 删除任务记录 instance deleteTaskRecord4OpenGauss 减少副本 instance reduceReplica 协调节点缩容 instance reduceCoordinatorNode 设置回收站策略 backup setRecyclePolicy 创建手动备份 backup createManualSnapshot 删除手动备份 backup deleteManualSnapshot 修改备份策略 backup setBackupPolicy 实例还原 backup restoreInstance 父主题: CTS 审计
共100000条