ITPub博客

SQL参考GaussDB200SQL关键字数据类型常量与宏函数和操作符表达式类型转换全文检索系统操作事务控制DDL语法一览表DML语法一览表DCL语法一览表SQL语法附录

背景信息GaussDB200提供了多种修改GUC参数的方法，用户可以方便的针对数据库、用户、会话进行设置。参数名称不区分大小写。参数取值有整型、浮点型、字符串、布尔型和枚举型五类。布尔值可以是（on，off）、（true，false）、（yes，no）或者（1，0），且不区分大小写。枚举类型的取值是

GaussDB200安装后，有一套默认的运行参数，为了使GaussDB200与业务的配合度更高，用户需要根据业务场景和数据量的大小进行GUC参数调整。操作步骤以操作系统用户omm登录CN所在主机，执行source${BIGDATA_HOME}/mppdb/.mppdbgs_profile命令启动环境

列存表可以选取某一列或几列设置为partialclusterkey(column_name[,...])。在导入数据时，按设置的列进行局部排序（默认每70个CU即420万行排序一次），生成的CU会聚集在一起，即CU的min,max会在一个较小的区间内。当查询时，where条件含有这些列时，可产生良好

现象描述in-clause/any-clause是常见的SQL语句约束条件，有时in或any后面的clause都是常量，类似于：selectcount(1)fromcalc_empfyc_c1_result_tmp_t1wherels_pid_cusr1in(‘20120405’,‘20130405

现象描述某局点测试中：ddw_f10_op_cust_asset_mon为分区表，分区键为year_mth，此字段是由年月两个值拼接而成的字符串。测试SQL如下：selectcount(1)fromt_ddw_f10_op_cust_asset_monb1whereb1.year_mthbetwee

现象描述某局点客户反馈如下SQL语句的执行时间超过1天未结束：UPDATEcalc_empfyc_c_cusr1t1SETln_rec_count=(SELECTCASEWHENcurrent_date-ln_process_date+1<=12THENELSEt2.ln_rec_countE

现象描述select1,(selectcount(*)fromcustomer_address_001a4wherea4.ca_address_sk=a.ca_address_sk)asGZCSfromcustomer_address_001a;此SQL性能较差，查看发现执行计划中存在SubPlan

现象描述t1的表定义为：createtablet1(aint,bint,cint)distributebyhash(a);假设agg下层算子所输出结果集的分布列为setA，agg操作的groupby列为setB，则在Stream框架下，Agg操作可以分为两个场景。setA是setB的一个子集。对于这

现象描述如下简单SQL语句查询，性能瓶颈点在dwcjk的Scan上。优化分析从业务层确认表数据(在cjrq字段上)有明显的日期特征，符合分区表的特征。重新规划dwcjk表的表定义：字段cjrq为分区键、天为间隔单位定义分区表dwcjk_part。修改后结果如下，性能提升近1倍。

现象描述某局点测试过程中出现如下计划，客户要求将性能提升至3s内返回。优化分析分析发现上述计划的性能瓶颈点为lfbank.f_ev_dp_kdpl_zhminx的scan。进一步分析此表的Scan条件如下：尝试把lfbank.f_ev_dp_kdpl_zhmin表修改为列存表，然后在yezdminc

现象描述在GaussDB200中行存表天然的使用行执行引擎，列存表天然的使用列执行引擎。如果一个SQL语句涉及的表既有行存表又有列存表，系统会自动选择行执行引擎。由于列执行引擎的性能(除indexscan相关的算子)比行执行引擎性能要好很多，因此一般建议使用列存表。特别是对一些中间结果集转储的表，一

现象描述某局点EXPLAINPERFORMANCE信息如下。分析发现如图红框标识的两个性能瓶颈点均为表Scan动作。优化分析进一步分析表Scan的filter条件发现两个表存在acct_id='A012709548'::bpchar这样的filter条件。试着给两个表的acct_id列增加局部聚簇键

现象描述某局点测试过程中EXPLAINANALYZE后有如下情况：从执行信息上比较明确的可以看出HashJoin是整个计划的性能瓶颈点，并且从HashJoin的执行时间信息[2657.406,93339.924](数值的具体含义请参见SQL执行计划详解)，上可以看出HashJoin在不同的DN上存在

现象描述1cost_param的bit0(setcost_param=1)值为1时，表示对于求!=连接的选择率时选择一种改良机制，此方法在自连接（两个相同的表之间连接）的估算中更加准确。下面查询的例子是cost_param的bit0为1时的优化场景。V300R002C00版本开始已弃用cost_pa

现象描述在做场景性能测试时，发现某场景大部分时间是CN端在做windowagg，占到总执行时间95%以上，系统资源不能充分利用。研究发现该场景的特点是：将两列分别求sum作为一个子查询，外层对两列的和再求和后做trunc，然后排序。表结构如下所示：CREATETABLEpublic.test(ims

现象描述SELECT*FROM((SELECTSTARTTIMESTTIME,SUM(NVL(PAGE_DELAY_MSEL,))PAGE_DELAY_MSEL,SUM(NVL(PAGE_SUCCEED_TIMES,))PAGE_SUCCEED_TIMES,SUM(NVL(FST_PAGE_REQ_

现象描述查询与销售部所有员工的信息：SELECTstaff_id,first_name,last_name,employment_id,state_name,cityFROMstaffs,sections,states,placesWHEREsections.section_name='Sales'

现象描述表定义如下：CREATETABLEt1(aint,bint);CREATETABLEt2(aint,bint);执行如下查询：SELECT*FROMt1,t2WHEREt1.a=t2.b;优化分析如果将a作为t1和t2的分布列：CREATETABLEt1(aint,bint)DISTRIBU

实际调优案例案例：选择合适的分布列案例：建立合适的索引案例：增加JOIN列非空条件案例：使排序下推案例：设置cost_param对查询性能优化案例：调整分布键案例：调整局部聚簇键案例：调整中间表存储方式案例：调整局部聚簇列案例：改建分区表案例：调整GUC参数best_agg_plan案例：改写SQL