云服务器内容精选

  • 其他算子 其他算子包括Stream算子,以及RemoteQuery等算子。Stream算子主要有三种类型:Gather stream、Broadcast stream及Redistribute stream。 Gather算子:每个源节点都将其数据发送给目标节点进行汇聚。 Broadcast stream:由一个源节点将其数据发给N个目标节点进行运算。 Redistrubute stream:每个源节点将其数据根据连接条件计算Hash值,根据重新计算的Hash值进行分布,发给对应的目标节点。 表5 其他算子 算子 含义 场景 Stream 多节点数据交换 执行分布式查询计划,节点间存在数据交换。 Partition Iterator 分区迭代器 分区表扫描,迭代扫描每个分区。 RowToVec 行转列 行列混合场景。 DfsScan / DfsIndexScan HDFS表(索引)扫描 HDFS表扫描。
  • 控制算子 控制算子是一类用于处理特殊情况的节点,用于实现特殊的执行流程。 表4 控制算子 算子 含义 场景 Result 直接进行计算 1. 不包含表扫描。 2. INSERT语句中只有一个VALUES子句。 3. 当 Append/MergeAppend为计划根节点(投影上推)。 ModifyTable INSERT/UPDATE/DELETE上层节点 INSERT/UPDATE/DELETE Append 追加 1. UNION(ALL)。 2. 继承表。 MergeAppend 追加(输入有序) 1. UNION(ALL)。 2. 继承表。 RecursiveUnion 处理WITH子句中递归定义的UNION子查询 WITH RECURSIVE … SELECT … 语句。 BitmapAnd Bitmap逻辑与操作 多维索引扫描的BitmapScan。 BitmapOr Bitmap逻辑或操作 多维索引扫描的BitmapScan。 Limit 处理LIMIT子句 OFFSET … LIMIT …
  • 物化算子 物化算子是一类可缓存元组的节点。在执行过程中,很多扩展的物理操作符需要首先获取所有的元组才能进行操作(例如聚集函数操作、没有索引辅助的排序等),这是要用物化算子将元组缓存起来; 表3 物化算子 算子 含义 场景 Material 物化 缓存子节点结果。 Sort 排序 ORDER BY子句,连接操作,分组操作,集合操作,配合Unique。 Group 分组操作 GROUP BY子句。 Agg 执行聚集函数 COUNT/SUM/AVG/MAX/MIN等聚集函数。 DISTINCT子句。 UNION去重。 GROUP BY子句。 WindowAgg 窗口函数 WINDOW子句。 Unique 去重(下层已排序) DISTINCT子句。 UNION去重。 Hash HashJoin辅助节点 构造hash表,配合HashJoin。 SetOp 处理集合操作 INTERSECT/INTERSECT ALL,EXCEPT/EXCEPT ALL LockRows 处理行级锁 SELECT … FOR SHARE/UPDATE
  • 连接算子 连接算子对应了关系代数中的连接操作,以表 t1 join t2 为例,主要的集中连接类型如下:inner join、left join、right join、full join、semi join、 anti join,其实现方式包括Nestloop、HashJoin及MergeJoin。 表2 连接算子 算子 含义 场景 实现特点 NestLoop 嵌套循环连接,暴力连接,对每一行都扫描内表。 Inner Join, Left Outer Join, Semi Join, Anti Join 适用于被连接的数据子集较小的查询。在嵌套循环中,外表驱动内表,外表返回的每一行都要在内表中检索找到它匹配的行,因此整个查询返回的结果集不能太大(不能大于10000),要把返回子集较小的表作为外表,而且在内表的连接字段上建议要有索引。 MergeJoin 归并连接(输入有序),内外表排序,定位首尾两端,一次性连接元组。等值连接。 Inner Join, Left Outer Join, Right Outer Join, Full Outer Join, Semi Join, Anti Join 也称作“融合连接”,是先将关联表的关联列各自做排序,然后从各自的排序表中抽取数据,到另一个排序表中做匹配。 因为Merge join需要做更多的排序,所以消耗的资源更多,因此通常情况下执行性能差于Hash Join。 如果源数据已经被排序过,在执行融合连接时,并不需要再排序,此时Merge Join的性能优于Hash Join。 (Sonic) HashJoin 哈希连接,内外表使用join列的hash值建立hash表,相同值的必在同一个hash桶。等值连接连接两端必须为类型相同的等值连接,且支持hash散列。 Inner Join, Left Outer Join, Right Outer Join, Full Outer Join, Semi Join, Anti Join 哈希连接,适用于数据量大的表的连接方式。优化器使用两个表中较小的表,利用连接键在内存中建立hash表,然后扫描较大的表并探测散列,找到与散列匹配的行。Sonic和非Sonic的Hash Join的区别在于所使用hash表结构不同,不影响执行的结果集。
  • 扫描算子 扫描算子用来扫描表中的数据,每次获取一条元组作为上层节点的输入, 存在于查询计划树的叶子节点,它不仅可以扫描表,还可以扫描函数的结果集、链表结构、子查询结果集。常见的扫描算子如下表所示: 表1 扫描算子 算子 含义 场景 SeqScan 顺序扫描 最基本的扫描算子,用于扫描物理表(没有索引辅助的顺序扫描)。 IndexScan 索引扫描 选择条件涉及的属性上建立了索引。 IndexOnlyScan 直接从索引返回元组 索引列完全覆盖结果集列。 BitmapScan(BitmapIndexScan, BitmapHeapScan) 利用Bitmap获取元组 BitmapIndexScan利用属性上的索引进行扫描,返回结果为一个位图;BitmapHeapScan从BitmapIndexScan输出的位图中获取元组。 TidScan 通过元组tid获取元组 WHERE conditions(like CTID = tid or CTID IN (tid1, tid2, …)) ; UPDATE/DELETE … WHERE CURRENT OF cursor; SubqueryScan 子查询扫描 以另一个查询计划树(子计划)为扫描对象进行元组的扫描。 FunctionScan 函数扫描 FROM function_name ValuesScan 扫描values链表 对VALUES子句给出的元组集合进行扫描。 ForeignScan 外部表扫描 查询外部表。 CteScan CTE表扫描 扫描SELECT查询中用WITH子句定义的子查询。
  • 检查隐式转换的性能问题 在某些场景下,数据类型的隐式转换可能会导致潜在的性能问题。请看如下的场景: 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; 为了提前识别隐式类型转换可能带来的性能影响,我们提供了一个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调优指南
  • 算子级调优介绍 一个查询语句要经过多个算子步骤才会输出最终的结果。由于各别算子耗时过长导致整体查询性能下降的情况比较常见。这些算子是整个查询的瓶颈算子。通用的优化手段是EXPLAIN ANALYZE/PERFORMANCE命令查看执行过程的瓶颈算子,然后进行针对性优化。 如下面的执行过程信息中,Hashagg算子的执行时间占总时间的:(51016-13535)/ 56476 ≈66%,此处Hashagg算子就是这个查询的瓶颈算子,在进行性能优化时应当优先考虑此算子的优化。
  • 相关概念 使用VACUUM、VACUUM FULL和ANALYZE命令定期对每个表进行维护,主要有以下原因: VACUUM FULL可回收已更新或已删除的数据所占据的磁盘空间,同时将小数据文件合并。 VACUUM对每个表维护了一个可视化映射来跟踪包含对别的活动事务可见的数组的页。一个普通的索引扫描首先通过可视化映射来获取对应的数组,来检查是否对当前事务可见。若无法获取,再通过堆数组抓取的方式来检查。因此更新表的可视化映射,可加速唯一索引扫描。 VACUUM可避免执行的事务数超过数据库阈值时,事务ID重叠造成的原有数据丢失。 ANALYZE可收集与数据库中表内容相关的统计信息。统计结果存储在系统表PG_STATISTIC中。查询优化器会使用这些统计数据,生成最有效的执行计划。
  • 操作步骤 使用VACUUM或VACUUM FULL命令,进行磁盘空间回收。 VACUUM: 对表执行VACUUM操作。 VACUUM customer; 可以与数据库操作命令并行运行。(执行期间,可正常使用的语句:SELECT、INSERT、UPDATE和DELETE。不可正常使用的语句:ALTER TABLE)。 对表分区执行VACUUM操作。 VACUUM customer_par PARTITION ( P1 ); VACUUM FULL: VACUUM FULL customer; 需要向正在执行的表增加排他锁,且需要停止其他所有数据库操作。 在进行磁盘空间回收时,用户可以使用如下命令查询集群中最早事务对应session,再根据需要结束最早执行的长事务,从而更加高效的利用磁盘空间。 使用命令从GTM上查询oldestxmin SELECT * FROM pgxc_gtm_snapshot_status(); 从CN上查询对应的session的pid,此处xmin为上一步的oldestxmin。 SELECT * FROM pgxc_running_xacts() where xmin=1400202010; 使用ANALYZE语句更新统计信息。 ANALYZE customer; 使用ANALYZE VERBOSE语句更新统计信息,并输出表的相关信息。 ANALYZE VERBOSE customer; 也可以同时执行VACUUM ANALYZE命令进行查询优化。 VACUUM ANALYZE customer; VACUUM和ANALYZE会导致I/O流量的大幅增加,这可能会影响其他活动会话的性能。因此,建议通过“vacuum_cost_delay”参数设置。
  • 背景信息 ANALYZE语句可收集与数据库中表内容相关的统计信息,统计结果存储在系统表PG_STATISTIC中。查询优化器会使用这些统计数据,以生成最有效的执行计划。 建议在执行了大批量插入/删除操作后,例行对表或全库执行ANALYZE语句更新统计信息。目前默认收集统计信息的采样比例是30000行(即:guc参数default_statistics_target默认设置为100),如果表的总行数超过一定行数(大于1600000),建议设置guc参数default_statistics_target为-2,即按2%收集样本估算统计信息。 对于在批处理脚本或者存储过程中生成的中间表,也需要在完成数据生成之后显式的调用ANALYZE。 对于表中多个列有相关性且查询中有同时基于这些列的条件或分组操作的情况,可尝试收集多列统计信息,以便查询优化器可以更准确地估算行数,并生成更有效的执行计划。
  • 不支持下推的函数 首先介绍函数的易变性。在 GaussDB (DWS)中共分三种形态: 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如果出现CTE中,也不下推。因为这种场景下推可能出现结果错误。 对于用户自定义函数,可以在创建函数的时候指定provolatile和proshippable属性的值,详细请参考CREATE FUNCTION。 对于函数不能下推的场景: 如果是系统函数,建议根据业务等价替换这个函数。 如果是自定义函数,建议分析客户业务场景,看函数的provolatile和proshippable属性定义是否正确。
  • 语句下推介绍 目前,GaussDB(DWS)优化器在分布式框架下制定语句的执行策略时,有三种执行计划方式:生成下推语句计划、生成分布式执行计划、生成发送语句的分布式执行计划。 下推语句计划:指直接将查询语句从CN发送到DN进行执行,然后将执行结果返回给CN。 分布式执行计划:指CN对查询语句进行编译和优化,生成计划树,再将计划树发送给DN进行执行,并在执行完毕后返回结果到CN。 发送语句的分布式执行计划:上述两种方式都不可行时,将可下推的查询部分组成查询语句(多为基表扫描语句)下推到DN进行执行,获取中间结果到CN,然后在CN执行剩下的部分。 在发送语句的分布式执行计划策略中,要将大量中间结果从DN发送到CN,并且要在CN运行不能下推的部分语句,会导致CN成为性能瓶颈(带宽、存储、计算等)。在进行性能调优的时候,应尽量避免只能选择该策略的查询语句。 执行语句不能下推是因为语句中含有不支持下推的函数或者不支持下推的语法。一般都可以通过等价改写规避执行计划不能下推的问题。
  • 统计信息调优介绍 GaussDB是基于代价估算生成的最优执行计划。优化器需要根据analyze收集的统计信息进行行数估算和代价估算,因此统计信息对优化器行数估算和代价估算起着至关重要的作用。通过analyze收集全局统计信息,主要包括:pg_class表中的relpages和reltuples,pg_statistic表中的stadistinct、stanullfrac、stanumbersN、stavaluesN、histogram_bounds等。
  • 相关链接 SQL PATCH相关系统函数、系统表、系统视图和接口函数见表1 SQL PATCH相关系统函数、系统表、系统视图和接口函数介绍。 表1 SQL PATCH相关系统函数、系统表、系统视图和接口函数介绍 类别 名称 说明 系统函数 global_sql_patch_func() 全局各个节点上的SQL PATCH信息,用于返回global_sql_patch视图的结果。 系统表 GS_SQL_PATCH GS_SQL_PATCH系统表存储所有SQL_PATCH的状态信息。 系统视图 GLOBAL_SQL_PATCH GLOBAL_SQL_PATCH视图存放所有SQL PATCH的信息,该视图仅在pg_catalog模式下存在。 接口函数 DBE_SQL_UTIL Schema DBE_SQL_UTIL.create_hint_sql_patch create_hint_sql_patch是用于在当前建连的CN上创建调优SQL PATCH的接口函数,返回执行是否成功。 DBE_SQL_UTIL.create_abort_sql_patch create_abort_sql_patch是用于在当前建连的CN上创建避险SQL PATCH的接口函数,返回执行是否成功。 DBE_SQL_UTIL.drop_sql_patch drop_sql_patch是用于在当前建连的CN上删除SQL PATCH的接口函数,返回执行是否成功。 DBE_SQL_UTIL.enable_sql_patch enable_sql_patch是用于在当前建连的CN上开启SQL PATCH的接口函数,返回执行是否成功。 DBE_SQL_UTIL.disable_sql_patch disable_sql_patch是用于在当前建连的CN上禁用SQL PATCH的接口函数,返回执行是否成功。 DBE_SQL_UTIL.show_sql_patch show_sql_patch是用于显示给定patch_name对应SQL PATCH的接口函数,返回运行结果。 DBE_SQL_UTIL.create_hint_sql_patch create_hint_sql_patch是用于创建调优SQL PATCH的接口函数,返回执行是否成功。本函数是原函数的重载函数,支持通过parent_unique_sql_id值限制hint patch的生效范围。 DBE_SQL_UTIL.create_abort_sql_patch create_abort_sql_patch是用于创建避险SQL PATCH的接口函数,返回执行是否成功。本函数是原函数的重载函数,支持通过parent_unique_sql_id值限制abort patch的生效范围。 DBE_SQL_UTIL.create_remote_hint_sql_patch create_remote_hint_sql_patch是用于指定CN创建调优SQL PATCH的接口函数,返回执行是否成功。 DBE_SQL_UTIL.create_remote_abort_sql_patch create_remote_abort_sql_patch是用于指定CN创建避险SQL PATCH的接口函数,返回执行是否成功。 DBE_SQL_UTIL.drop_remote_sql_patch drop_remote_sql_patch是用于指定CN删除SQL PATCH的接口函数,返回执行是否成功。 DBE_SQL_UTIL.enable_remote_sql_patch enable_remote_sql_patch是用于指定CN开启SQL PATCH的接口函数,返回执行是否成功。 DBE_SQL_UTIL.disable_remote_sql_patch disable_remote_sql_patch是用于指定CN禁用SQL PATCH的接口函数,返回执行是否成功。
  • 特性约束 仅支持针对Unique SQL ID添加补丁,如果存在Unique SQL ID冲突,用于hint调优的SQL PATCH可能影响性能,但不影响语义正确性。 仅支持不改变SQL语义的hint作为PATCH,不支持SQL改写。 不支持逻辑备份、恢复。 不支持在DN上创建SQL PATCH。 仅初始用户、运维管理员、监控管理员、系统管理员用户有权限执行。 库之间不共享,创建SQL PATCH时需要连接目标库。如果创建SQL PATCH的CN被剔除并触发全量Build,则会继承全量Build的目标CN中的SQL PATCH,因此建议在各个CN上尽量都创建对应的SQL PATCH。 CN之间由于Unique SQL ID不同,不共享SQL PATCH,需要用户手动在不同的CN上创建对应的SQL PATCH。 限制在存储过程内的SQL PATCH和全局的SQL PATCH不允许同时存在。 使用PREPARE + EXECUTE语法执行的预编译语句执行不支持使用SQL PATCH。存在特殊情况,请参见特殊说明。 SQL PATCH不建议在数据库中长期使用,只应该作为临时规避方法。遇到内核问题所导致的特定语句触发数据库服务不可用问题,以及使用hint进行调优的场景,需要尽快修改业务或升级内核版本解决问题。并且升级后由于Unique SQL ID生成方法可能变化,可能导致规避方法失效。 当前,除DML语句之外,其他SQL语句(如CREATE TABLE等)的Unique SQL ID是对语句文本直接哈希生成的,所以对于此类语句,SQL PATCH对大小写、空格、换行等敏感,即不同文本的语句,即使语义相同,仍然需要对应不同的SQL PATCH。对于DML,则同一个SQL PATCH可以对不同入参的语句生效,并且忽略大小写和空格。