华为云用户手册

创建时序表（手动设置分区边界） 手动指定分区边界的起始值。例如，手动设置默认的分区边界时间P1为“2022-05-30 16:32:45”、P2为“2022-05-31 16:56:12”，创建时序表GENERATOR1： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 CREATE TABLE IF NOT EXISTS GENERATOR1( genset text TSTag, manufacturer text TSTag, model text TSTag, location text TSTag, ID bigint TSTag, voltage numeric TSField, power bigint TSField, frequency numeric TSField, angle numeric TSField, time timestamptz TSTime) with (orientation=TIMESERIES, period='1 day') distribute by hash(model) partition by range(time) ( PARTITION P1 VALUES LESS THAN('2022-05-30 16:32:45'), PARTITION P2 VALUES LESS THAN('2022-05-31 16:56:12') ); 查询当前时间： 1 2 3 4 select now(); now ------------------------------- 2022-05-31 20:36:09.700096+08(1 row) 查询分区以及分区边界： 1 2 3 4 5 6 7 8 SELECT relname, boundaries FROM pg_partition where parentid=(SELECT oid FROM pg_class where relname='generator1') order by boundaries ; relname | boundaries -------------+---------------------------- p1 | {"2022-05-30 16:32:45+08"} p2 | {"2022-05-31 16:56:12+08"} p1654073772 | {"2022-06-01 16:56:12+08"} p1654160172 | {"2022-06-02 16:56:12+08"} ......

场景介绍 时序表继承普通表的行存和列存语法，降低了用户学习成本，易理解和使用。 时序表具备数据生命周期管理的能力，每天各种维度的数据爆炸式增长，需要定期给表增加新的分区，避免新数据无法存储。而对于很久之前的数据，其价值较低且不经常访问，可以定期删除无用的数据。因此时序表需要具备定时增加分区和定时删除分区的能力。 本实践主要讲解如何快速创建适合自己业务的时序表，并对时序表进行分区管理，从而真正发挥时序表的优势。将对应的列指定为合适的类型，能够帮助用户更好的提高导入、查询等场景的性能，让业务场景运行的更加高效。如下图所示，以发电机组数据采样为例： 图1 发电机组数据采样示意图

支持区域 当前已上传OBS数据的区域如表1所示。 表1 区域和OBS桶名 区域 OBS桶名 华北-北京一 dws-demo-cn-north-1 华北-北京二 dws-demo-cn-north-2 华北-北京四 dws-demo-cn-north-4 华北-乌兰察布一 dws-demo-cn-north-9 华东-上海一 dws-demo-cn-east-3 华东-上海二 dws-demo-cn-east-2 华南-广州 dws-demo-cn-south-1 华南-广州友好 dws-demo-cn-south-4 中国-香港 dws-demo-ap-southeast-1 亚太-新加坡 dws-demo-ap-southeast-3 亚太-曼谷 dws-demo-ap-southeast-2 拉美-圣地亚哥 dws-demo-la-south-2 非洲-约翰内斯堡 dws-demo-af-south-1 拉美-墨西哥城一 dws-demo-na-mexico-1 拉美-墨西哥城二 dws-demo-la-north-2 莫斯科二 dws-demo-ru-northwest-2 拉美-圣保罗一 dws-demo-sa-brazil-1

场景描述 了解 GaussDB (DWS)的基本功能和数据导入，对某公司与供应商的订单数据分析，分析维度如下： 分析某地区供应商为公司带来的收入，通过该统计信息可用于决策在给定的区域是否需要建立一个当地分配中心。 分析零件/供货商关系，可以获得能够以指定的贡献条件供应零件的供货商数量，通过该统计信息可用于决策在订单量大，任务紧急时，是否有充足的供货商。 分析小订单收入损失，通过查询得知如果没有小量订单，平均年收入将损失多少。筛选出比平均供货量的20％还低的小批量订单，如果这些订单不再对外供货，由此计算平均一年的损失。

创建冷热表 创建列存冷热数据管理表lifecycle_table，指定热数据有效期LMT为100天。 1 2 3 4 5 6 7 8 9 CREATE TABLE lifecycle_table(i int, val text) WITH (ORIENTATION = COLUMN, storage_policy = 'LMT:100') PARTITION BY RANGE (i) ( PARTITION P1 VALUES LESS THAN(5), PARTITION P2 VALUES LESS THAN(10), PARTITION P3 VALUES LESS THAN(15), PARTITION P8 VALUES LESS THAN(MAXVALUE) ) ENABLE ROW MOVEMENT;

查看冷热表数据分布 查看单表数据分布情况。 1 2 3 4 5 6 7 SELECT * FROM pg_catalog.pg_lifecycle_table_data_distribute('lifecycle_table'); schemaname | tablename | nodename | hotpartition | coldpartition | switchablepartition | hotdatasize | colddatasize | switchabledatasize ------------+-----------------+--------------+--------------+---------------+---------------------+-------------+--------------+-------------------- public | lifecycle_table | dn_6001_6002 | p1,p2,p3,p8 | | | 96 KB | 0 bytes | 0 bytes public | lifecycle_table | dn_6003_6004 | p1,p2,p3,p8 | | | 96 KB | 0 bytes | 0 bytes public | lifecycle_table | dn_6005_6006 | p1,p2,p3,p8 | | | 96 KB | 0 bytes | 0 bytes (3 rows) 查看所有冷热表数据分布情况。 1 2 3 4 5 6 7 SELECT * FROM pg_catalog.pg_lifecycle_node_data_distribute(); schemaname | tablename | nodename | hotpartition | coldpartition | switchablepartition | hotdatasize | colddatasize | switchabledatasize ------------+-----------------+--------------+--------------+---------------+---------------------+-------------+--------------+-------------------- public | lifecycle_table | dn_6001_6002 | p1,p2,p3,p8 | | | 98304 | 0 | 0 public | lifecycle_table | dn_6003_6004 | p1,p2,p3,p8 | | | 98304 | 0 | 0 public | lifecycle_table | dn_6005_6006 | p1,p2,p3,p8 | | | 98304 | 0 | 0 (3 rows)

场景介绍 海量大数据场景下，随着业务和数据量的不断增长，数据存储与消耗的资源也日益增长。根据业务系统中用户对不同时期数据的不同使用需求，对膨胀的数据进行“冷热”分级管理，不仅可以提高数据分析性能还能降低业务成本。针对数据使用的一些场景，可以将数据按照时间分为：热数据、冷数据。 冷热数据主要从数据访问频率、更新频率进行划分。 Hot（热数据）：访问、更新频率较高，对访问的响应时间要求很高的数据。 Cold（冷数据）：不允许更新或更新访问频率较低，对访问的响应时间要求不高的数据。 用户可以定义冷热管理表，将符合规则的冷数据切换至OBS上进行存储，可以按照分区自动进行冷热数据的判断和迁移。 图1 冷热数据管理 冷热切换的策略名称支持LMT（last modify time）和HPN（hot partition number），LMT指按分区的最后更新时间切换，HPN指保留热分区的个数切换。 LMT：表示切换[day]时间前修改的热分区数据为冷分区，将该数据迁至OBS表空间中。其中[day]为整型，范围[0, 36500]，单位为天。 HPN：表示保留HPN个有数据的分区为热分区。在冷热切换时，需要将数据迁移至OBS表空间中。其中HPN为整型，范围为[0,1600]。

冷热数据切换 切换冷数据至OBS表空间。 自动切换：每日0点调度框架自动触发，无需关注切换情况。 可使用函数pg_obs_cold_refresh_time(table_name, time)自定义自动切换时间。例如，根据业务情况调整自动触发时间为每天早晨6点30分。 1 2 3 4 5 SELECT * FROM pg_obs_cold_refresh_time('lifecycle_table', '06:30:00'); pg_obs_cold_refresh_time -------------------------- SUC CES S (1 row) 手动切换。 使用ALTER TABLE语句手动切换单表： 1 2 ALTER TABLE lifecycle_table refresh storage; ALTER TABLE 使用函数pg_refresh_storage()批量切换所有冷热表： 1 2 3 4 5 SELECT pg_catalog.pg_refresh_storage(); pg_refresh_storage -------------------- (1,0) (1 row)

约束限制 在使用分区管理功能时，需要满足如下约束： 不支持在小型机、加速集群、单机集群上使用。 支持在8.1.3及以上集群版本中使用。 仅支持行存范围分区表、列存范围分区表、时序表以及冷热表。 分区键唯一且类型仅支持timestamp、timestamptz、date类型。 不支持存在maxvalue分区。 (nowTime - boundaryTime) / period需要小于分区个数上限，其中nowTime为当前时间，boundaryTime为现有分区中最早的分区边界时间。 period、ttl取值范围为1hour ~ 100years。另外，在兼容Teradata或MySQL的数据库中，分区键类型为date时，period不能小于1day。 表级参数ttl不支持单独存在，必须要提前或同时设置period，并且要大于或等于period。 集群在线扩容期间，自动增加分区会失败，但是由于每次增分区时，都预留了足够的分区，所以不影响使用。

分区自动管理 分区管理功能是和表级参数period、ttl绑定的，只要成功设置了表级参数period，即开启了自动创建新分区功能；成功设置了表级参数ttl，即开启了自动删除过期分区功能。第一次自动创建分区或删除分区的时间为设置period或ttl后30秒。 有如下两种开启分区管理功能的方式： 建表时指定period、ttl。 该方式适用于新建分区管理表时使用。新建分区管理表有两种语法：一种是建表时指定分区，另一种是建表时不指定分区。 建分区管理表时如果指定分区，则语法规则和建普通分区表相同，唯一的区别就是会指定表级参数period、ttl。 示例：创建分区管理表CPU1，指定分区。 1 2 3 4 5 6 7 8 9 10 CREATE TABLE CPU1( id integer, IP text, time timestamp ) with (TTL='7 days',PERIOD='1 day') partition by range(time) ( PARTITION P1 VALUES LESS THAN('2023-02-13 16:32:45'), PARTITION P2 VALUES LESS THAN('2023-02-15 16:48:12') ); 建分区管理表时可以只指定分区键不指定分区，此时将创建两个默认分区，这两个默认分区的分区时间范围均为period。其中，第一个默认分区的边界时间是大于当前时间的第一个整时/整天/整周/整月/整年的时间，具体选择哪种整点时间取决于period的最大单位；第二个默认分区的边界时间是第一个分区边界时间加period。假设当前时间是2023-02-17 16:32:45，各种情况的第一个默认分区的分区边界选择如下表： 表2 period参数说明 period period最大单位 第一个默认分区的分区边界 1hour Hour 2023-02-17 17:00:00 1day Day 2023-02-18 00:00:00 1month Month 2023-03-01 00:00:00 13months Year 2024-01-01 00:00:00 创建分区管理表CPU2，不指定分区： 1 2 3 4 5 6 CREATE TABLE CPU2( id integer, IP text, time timestamp ) with (TTL='7 days',PERIOD='1 day') partition by range(time); 使用ALTER TABLE RESET的方式设置period、ttl。 该方式适用于给一张满足分区管理约束的普通分区表增加分区管理功能。 创建普通分区表CPU3： 1 2 3 4 5 6 7 8 9 10 CREATE TABLE CPU3( id integer, IP text, time timestamp ) partition by range(time) ( PARTITION P1 VALUES LESS THAN('2023-02-14 16:32:45'), PARTITION P2 VALUES LESS THAN('2023-02-15 16:56:12') ); 同时开启自动创建和自动删除分区功能： 1 ALTER TABLE CPU3 SET (PERIOD='1 day',TTL='7 days'); 只开启自动创建分区功能： 1 ALTER TABLE CPU3 SET (PERIOD='1 day'); 只开启自动删除分区功能，如果没有提前开启自动创建分区功能，则开启失败： 1 ALTER TABLE CPU3 SET (TTL='7 days'); 通过修改period和ttl修改分区管理功能： 1 ALTER TABLE CPU3 SET (TTL='10 days',PERIOD='2 days'); 关闭分区管理功能。 使用ALTER TABLE RESET语句可以删除表级参数period、ttl，即可关闭相应的分区管理功能。 不能在存在ttl的情况下，单独删除period。 时序表不支持ALTER TABLE RESET。 同时关闭自动创建和自动删除分区功能： 1 ALTER TABLE CPU1 RESET (PERIOD,TTL); 只关闭自动删除分区功能： 1 ALTER TABLE CPU3 RESET (TTL); 只关闭自动创建分区功能，如果该表有ttl参数，则关闭失败： 1 ALTER TABLE CPU3 RESET (PERIOD);

零售业百货公司样例简介 本实践将演示以下场景：从OBS加载各个零售商场每日经营的业务数据到 数据仓库 对应的表中，然后对商铺营业额、客流信息、月度销售排行、月度客流转化率、月度租售比、销售坪效等KPI信息进行汇总和查询。本示例旨在展示在零售业场景中GaussDB(DWS) 数据仓库的多维度查询分析的能力。 GaussDB(DWS) 已预先将样例数据上传到OBS桶的“retail-data”文件夹中，并给所有华为云用户赋予了该OBS桶的只读访问权限。

支持区域 当前已上传OBS数据的区域如表1所示。 表1 区域和OBS桶名 区域 OBS桶名 华北-北京一 dws-demo-cn-north-1 华北-北京二 dws-demo-cn-north-2 华北-北京四 dws-demo-cn-north-4 华北-乌兰察布一 dws-demo-cn-north-9 华东-上海一 dws-demo-cn-east-3 华东-上海二 dws-demo-cn-east-2 华南-广州 dws-demo-cn-south-1 华南-广州友好 dws-demo-cn-south-4 中国-香港 dws-demo-ap-southeast-1 亚太-新加坡 dws-demo-ap-southeast-3 亚太-曼谷 dws-demo-ap-southeast-2 拉美-圣地亚哥 dws-demo-la-south-2 非洲-约翰内斯堡 dws-demo-af-south-1 拉美-墨西哥城一 dws-demo-na-mexico-1 拉美-墨西哥城二 dws-demo-la-north-2 莫斯科二 dws-demo-ru-northwest-2 拉美-圣保罗一 dws-demo-sa-brazil-1

算子级调优介绍 一个查询语句要经过多个算子步骤才会输出最终的结果。由于个别算子耗时过长导致整体查询性能下降的情况比较常见。这些算子是整个查询的瓶颈算子。通用的优化手段是EXPLAIN ANALYZE/PERFORMANCE命令查看执行过程的瓶颈算子，然后进行针对性优化。 如下面的执行过程信息中，Hashagg算子的执行时间占总时间的：(51016-13535)/ 56476 ≈66%，此处Hashagg算子就是这个查询的瓶颈算子，在进行性能优化时应当优先考虑此算子的优化。

优化前 in-clause/any-clause是常见的SQL语句约束条件，有时in或any后面的clause都是常量，类似于： 1 2 3 4 select count(1) from calc_empfyc_c1_result_tmp_t1 where ls_pid_cusr1 in (‘20120405’, ‘20130405’); 或者 1 2 3 4 select count(1) from calc_empfyc_c1_result_tmp_t1 where ls_pid_cusr1 in any(‘20120405’, ‘20130405’); 但是也有一些如下的特殊用法： 1 2 3 4 5 SELECT ls_pid_cusr1,COALESCE(max(round((current_date-bthdate)/365)),0) FROM calc_empfyc_c1_result_tmp_t1 t1,p10_md_tmp_t2 t2 WHERE t1.ls_pid_cusr1 = any(values(id),(id15)) GROUP BY ls_pid_cusr1; 其中，id、id15为p10_md_tmp_t2中的两列，“t1.ls_pid_cusr1 = any(values(id),(id15))”等价于“t1.ls_pid_cusr1 = id or t1.ls_pid_cusr1 = id15”。 因此join-condition实质上是一个不等式，这种不等值的join操作必须走nestloop，对应执行计划如下：

优化后 测试发现由于两表结果集过大，导致nestloop耗时过长，超过一小时未返回结果，因此性能优化的关键是消除nestloop，让join走更高效的hashjoin。从语义等价的角度消除any-clause，SQL改写如下： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 select ls_pid_cusr1,COALESCE(max(round(ym/365)),0) from ( ( SELECT ls_pid_cusr1,(current_date-bthdate) as ym FROM calc_empfyc_c1_result_tmp_t1 t1,p10_md_tmp_t2 t2 WHERE t1.ls_pid_cusr1 = t2.id and t1.ls_pid_cusr1 != t2.id15 ) union all ( SELECT ls_pid_cusr1,(current_date-bthdate) as ym FROM calc_empfyc_c1_result_tmp_t1 t1,p10_md_tmp_t2 t2 WHERE t1.ls_pid_cusr1 = id15 ) ) GROUP BY ls_pid_cusr1; 注意：尽量使用union all代替union。union在合并两个集合时会执行去重操作，而union all则直接将两个结果集合并、不执行去重。执行去重会消耗大量的时间，因此，在一些实际应用场景中，如果通过业务逻辑已确认两个集合不存在重叠，可用union all替代union以便提升性能。 优化后的SQL查询由两个等值join的子查询构成，而每个子查询都可以走更适合此场景的hashjoin。优化后的执行计划如下 优化后，从超过1个小时未返回结果优化到7s返回结果。

建议 推荐使用两个表*的hint。对于两个表的采用*操作符的hint，只要两个表出现在join的两端，都会触发hint。例如：设置hint为rows(t1 t2 * 3)，对于(t1 t3 t4)和(t2 t5 t6)join时，由于t1和t2出现在join的两端，所以其join的结果集也会应用该hint规则乘以3。 rows hint支持在单表、多表、function table及subquery scan table的结果集上指定hint。

总结 通常优化器总会选择最优的执行计划，但是众所周知代价估算，尤其是中间结果集的代价估算一般会有比较大的偏差，这种比较大的偏差就可能会导致agg的计算方式出现比较大的偏差，这时候就需要通过best_agg_plan进行agg计算模型的干预。 一般来说，当agg汇聚的收敛度很小时，即结果集的个数在agg之后并没有明显变少时（经验上以5倍为临界点），选择redistribute+hashagg执行方式，否则选择hashagg+redistribute+hashagg执行方式。

hint的错误类型 语法错误 语法规则树归约失败，会报错，指出出错的位置。 例如：hint关键字错误，leading hint或join hint指定2个表以下，其它hint未指定表等。一旦发现语法错误，则立即终止hint的解析，所以此时只有错误前面的解析完的hint有效。 例如： 1 leading((t1 t2)) nestloop(t1) rows(t1 t2 #10) nestloop(t1)存在语法错误，则终止解析，可用hint只有之前解析的leading((t1 t2))。 语义错误 表不存在，存在多个，或在leading或join中出现多次，均会报语义错误。 scanhint中的index不存在，会报语义错误。 另外，如果子查询提升后，同一层出现多个名称相同的表，且其中某个表需要被hint，hint会存在歧义，无法使用，需要为相同表增加别名规避。 hint重复或冲突 如果存在hint重复或冲突，只有第一个hint生效，其它hint均会失效，会给出提示。 hint重复是指，hint的方法及表名均相同。例如：nestloop(t1 t2) nestloop(t1 t2)。 hint冲突是指，table list一样的hint，存在不一样的hint，hint的冲突仅对于每一类hint方法检测冲突。 例如：nestloop (t1 t2) hashjoin (t1 t2)，则后面与前面冲突，此时hashjoin的hint失效。注意：nestloop(t1 t2)和no mergejoin(t1 t2)不冲突。 leading hint中的多个表会进行拆解。例如：leading ((t1 t2 t3))会拆解成：leading((t1 t2)) leading(((t1 t2) t3))，此时如果存在leading((t2 t1))，则两者冲突，后面的会被丢弃。（例外：指定内外表的hint若与不指定内外表的hint重复，则始终丢弃不指定内外表的hint。） 子链接提升后hint失效 子链接提升后的hint失效，会给出提示。通常出现在子链接中存在多个表连接的场景。提升后，子链接中的多个表不再作为一个整体出现在join中。 列类型不支持重分布 对于skew hint来说，目的是为了进行重分布时的调优，所以当hint列的类型不支持重分布时，hint将无效。 hint未被使用 非等值join使用hashjoin hint或mergejoin hint 不包含索引的表使用indexscan hint或indexonlyscan hint 通常只有在索引列上使用过滤条件才会生成相应的索引路径，全表扫描将不会使用索引，因此使用indexscan hint或indexonlyscan hint将不会使用 indexonlyscan只有输出列仅包含索引列才会使用，否则指定时hint不会被使用 多个表存在等值连接时，仅尝试有等值连接条件的表的连接，此时没有关联条件的表之间的路径将不会生成，所以指定相应的leading，join，rows hint将不使用，例如：t1 t2 t3表join，t1和t2, t2和t3有等值连接条件，则t1和t3不会优先连接，leading(t1 t3)不会被使用。 生成stream计划时，如果表的分布列与join列相同，则不会生成redistribute的计划；如果不同，且另一表分布列与join列相同，只能生成redistribute的计划，不会生成broadcast的计划，指定相应的hint则不会被使用。 对于AGG重分布列的hint，hint未被使用的可能原因如下： 指定的分布键包含不支持重分布的数据类型。 执行计划中不需要重分布。 执行的分布键的序号有误。 对于使用grouping sets子句和cube子句的AP函数，window agg中的分布键，不支持hint。 指定Agg重分布列Hint，仅8.1.3.100及以上集群版本支持。 如果子链接未被提升，则blockname hint不会被使用。 对于skew hint，hint未被使用的可能原因如下： 计划中不需要进行重分布。 hint指定的列为包含分布键。 hint指定倾斜信息有误或不完整，如对于join优化未指定值。 倾斜优化的GUC参数处于关闭状态。 对于guc hint，hint未被使用的可能原因如下： 配置参数不存在。 配置参数不支持guc hint。 配置参数的值无效。 语句级别的guc hint没有被写在顶层查询中。 子查询级别的guc hint设置的配置参数不支持在子查询级别设置。 guc hint所在的子查询被提升。

调优手段之统计信息 GaussDB(DWS)优化器是典型的基于代价的优化 (Cost-Based Optimization，简称CBO)。在这种优化器模型下，数据库根据表的元组数、字段宽度、NULL记录比率、distinct值、MCV值、HB值等表的特征值，以及一定的代价计算模型，计算出每一个执行步骤的不同执行方式的输出元组数和执行代价（cost），进而选出整体执行代价最小/首元组返回代价最小的执行方式进行执行。这些特征值就是统计信息。从上面描述可以看出统计信息是查询优化的核心输入，准确的统计信息将帮助优化器选择最合适的查询规划，一般来说通过ANALYZE语法收集整个表或者表的若干个字段的统计信息，周期性地运行ANALYZE，或者在对表的大部分内容做了更改之后马上运行它是个好习惯。

调优手段之GUC参数 查询优化的主要目的是为查询语句选择高效的执行方式。 如下SQL语句: 1 2 SELECT count(1) FROM customer inner join store_sales on (ss_customer_sk = c_customer_sk); 在执行customer inner join store_sales的时候，GaussDB(DWS)支持Nested Loop、Merge Join和Hash Join三种不同的Join方式。优化器会根据表customer和表store_sales的统计信息估算结果集的大小以及每种join方式的执行代价，然后对比选出执行代价最小的执行计划。 正如前面所说，执行代价计算都是基于一定的模型和统计信息进行估算，当因为某些原因代价估算不能反映真实的cost的时候，就需要通过guc参数设置的方式让执行计划倾向更优规划。

优化后 将查询中的关联条件作为分布键，执行下列语句修改b作为t2的分布列： 1 ALTER TABLE t2 DISTRIBUTE BY HASH (b); 将表t2的分布列改为b列之后，执行计划将不再包含“Streaming(type: REDISTRIBUTE)”，减少了DN之间存在的通信数据量的同时，执行时间也从8.7毫秒降低至2.7毫秒，从而提升查询性能，如图2所示。 图2 选择合适的分布列案例（二）

优化前 将a作为t1和t2的分布列，表定义如下： 1 2 CREATE TABLE t1 (a int, b int) DISTRIBUTE BY HASH (a); CREATE TABLE t2 (a int, b int) DISTRIBUTE BY HASH (a); 执行如下查询： 1 SELECT * FROM t1, t2 WHERE t1.a = t2.b; 则执行计划存在“Streaming(type: REDISTRIBUTE)”，即DN根据选定的列把数据重分布到所有的DN，这将导致DN之间存在较大通信数据量，如图1所示。 图1 选择合适的分布列案例（一）

概述 GaussDB(DWS)实现基于query_band的负载识别和队列内优先级控制，一方面提供了更为灵活的负载识别手段，可根据作业类型、应用名称、脚本名称等识别负载队列，使用户根据业务场景可灵活配置query_band识别队列；另一方面实现了队列内作业下发优先级控制，后续将逐步实现队列内资源优先级控制。 管理员用户可根据业务场景及作业类别配置query_band所关联队列及估算内存限制等实现更为灵活的负载控制与资源管控。如果业务未配置query_band或用户未将query_band关联行为时，作业会默认使用用户关联队列和队列内优先级。

示例 设置query_band“JobName=abc”关联资源池p1、队列内优先级Rush、次序为1。 1 2 3 4 5 SELECT * FROM gs_wlm_set_queryband_action('JobName=abc','respool=p1;priority=rush',1); gs_wlm_set_queryband_action ----------------------------- t (1 row) 修改query_band“JobName=abc”的关联资源池为p2。 1 2 3 4 5 SELECT * FROM gs_wlm_set_queryband_action('JobName=abc','respool=p2'); gs_wlm_set_queryband_action ----------------------------- t (1 row) 修改query_band“JobName=abc”的队列内优先级为High。 1 2 3 4 5 SELECT * FROM gs_wlm_set_queryband_action('JobName=abc','priority=high'); gs_wlm_set_queryband_action ----------------------------- t (1 row) 修改query_band“JobName=abc”的次序为3。 1 2 3 4 5 SELECT * FROM gs_wlm_set_queryband_order('JobName=abc',3); gs_wlm_set_queryband_order ----------------------------- t (1 row) 查询query_band关联的负载行为。 1 2 3 4 5 6 SELECT * FROM pg_queryband_action; qband | respool_id | respool | priority | qborder --------------+------------+---------+----------+--------- AppName=test | 16974 | p1 | low | -1 JobName=abc | 17119 | p2 | high | 1 (2 rows)

query_band支持的负载行为 query_band是一个session级别的GUC参数，作为作业标识符本身没有特殊含义，数据类型为字符型，支持赋值任何字符串。但是为方便区分和设置，query_band负载识别仅支持识别键值对形式的query_band，示例： SET query_band='JobName=abc;AppName=test;UserName=user'; 其中，‘JobName=abc’，‘AppName=test’以及‘UserName=user’都是一个独立的键值对。query_band键值对规格： query_band使用键值对方式设置，即'key=value'；session内支持设置多个query_band键值对，多个键值对之间使用分号分隔。query_band键值对和query_band参数值长度的上限均为1024个字符。 query_band键值对支持的有效字符包括：数字0~9、大写字母A~Z、小写字母a-z、'.'、'-'、'_' 以及'#'。 query_band负载识别以键值对为单位设置和识别负载行为，目前支持的负载行为，如表1所示： 表1 QUERY_BAND支持负载行为 类别 行为 行为表现 负载管理(workload) 资源池(respool) query_band关联资源池 负载管理(workload) 优先级(priority) 队列内优先级 次序(order) 队列（respool） 目前为无效字段，主要用于后续扩展。 query_band搜索次序 其中，行为类别用于负载行为归类，不同的负载行为可能属于同一个类别，比如资源池和优先级同属于负载管理类别；负载行为代表query_band键值对关联的是哪种负载行为；行为表现用于记录具体的负载行为是什么；负载类别中的次序用于标记query_band负载行为识别的优先级，一个session内设置多个query_band键值对时，优先使用次序较小的query_band键值对识别负载行为。每一个query_band键值对都可以对应0个或多个负载行为，但是一种负载行为只能关联一个。query_band负载行为详细说明如下： 资源池：query_band支持关联资源池，作业执行时，若query_band指定了资源池，则使用query_band关联的资源池，否则使用用户关联的资源池。 query_band关联资源池时，资源池不存在报错退出，关联失败。 query_band关联资源池时，记录query_band与资源池依赖关系。 query_band关联资源池删除时，提示有query_band依赖，资源池删除失败。 队列内优先级：query_band支持关联作业优先级，支持高中低(High/Medium/Low)三个优先级，同时提供Rush作为特殊优先级（绿色通道），默认优先级为Medium。正常实践过程中，大部分作业使用Medium优先级，优先级较低作业使用Low优先级，特权作业使用High优先级，High作业不建议过多。Rush优先级作为特殊场景下应急使用，平时不建议使用。 队列内优先级实现队列内排队优先级： 静态负载管理场景下，CN并发不足时，触发CN全局队列排队，CN全局队列为优先级队列。 动态负载管理场景下，DN内存不足时，触发CCN全局队列排队，CCN全局队列为优先级队列。 资源池并发或内存不足时，触发资源池排队，资源池队列为优先级队列。 以上优先级队列均遵守以下调度规则： 优先级高作业优先调度。 优先级高作业全部调度完之后调度优先级低作业。 动态负载管理场景下，CN全局队列不支持query_band优先级。 次序：支持设置query_band识别次序，未设置识别次序的使用默认次序-1。除默认次序外，不存在次序相同的两个query_band。设置次序时对query_band次序进行校验，存在相同次序时，已存在次序递归+1直到不存在相同次序为止。 session内设置多个query_band键值对时，使用次序较小的query_band键值对作为负载识别的query_band。 次序最小为0，默认次序-1为最大次序。 次序都为默认次序时，使用设置靠前的query_band作为负载识别的query_band。 示例：set query_band='b=1;a=3;c=1'; b=1，其中b=1次序-1，a=3次序4，c=1次序1，则使用c=1作为负载识别的query_band，此设计可提供负载管理员对负载调度调整能力。

场景二：优化前 当cost_param的bit1（set cost_param=2）为1时，表示求多个过滤条件（Filter）的选择率时，选择最小的作为总的选择率，而非两者乘积，此方法在过滤条件的列之间关联性较强时估算更加准确。下面查询的例子是cost_param的bit1为1时的优化场景。 表结构如下所示： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 CREATE TABLE NATION ( N_NATIONKEYINT NOT NULL , N_NAMECHAR(25) NOT NULL , N_REGIONKEYINT NOT NULL , N_COMMENTVARCHAR(152) ) distribute by replication; CREATE TABLE SUPPLIER ( S_SUPPKEYBIGINT NOT NULL , S_NAMECHAR(25) NOT NULL , S_ADDRESSVARCHAR(40) NOT NULL , S_NATIONKEYINT NOT NULL , S_PHONECHAR(15) NOT NULL , S_ACCTBALDECIMAL(15,2) NOT NULL , S_COMMENTVARCHAR(101) NOT NULL ) distribute by hash(S_SUPPKEY); CREATE TABLE PARTSUPP ( PS_PARTKEYBIGINT NOT NULL , PS_SUPPKEYBIGINT NOT NULL , PS_AVAILQTYBIGINT NOT NULL , PS_SUPPLYCOSTDECIMAL(15,2)NOT NULL , PS_COMMENTVARCHAR(199) NOT NULL )distribute by hash(PS_PARTKEY); 查询语句如下所示： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 set cost_param=2; explain verbose select nation, sum(amount) as sum_profit from ( select n_name as nation, l_extendedprice * (1 - l_discount) - ps_supplycost * l_quantity as amount from supplier, lineitem, partsupp, nation where s_suppkey = l_suppkey and ps_suppkey = l_suppkey and ps_partkey = l_partkey and s_nationkey = n_nationkey ) as profit group by nation order by nation; 当cost_param的bit1为0时，执行计划如下图所示：

场景二：优化后 在以上查询中，supplier、lineitem、partsupp三表做hashjoin的条件为(lineitem.l_suppkey = supplier.s_suppkey) AND (lineitem.l_partkey = partsupp.ps_partkey)，此hashjoin条件中存在两个过滤条件，这前一个过滤条件中的lineitem.l_suppkey和后一个过滤条件中的lineitem.l_partkey同为lineitem表的两列，这两列存在强相关的关联关系。在这种情况，估算hashjoin条件的选择率时，如果使用cost_param的bit1为0时，实际是将AND的两个过滤条件分别计算的2个选择率的值相乘来得到hashjoin条件的选择率，导致行数估算不准确，查询性能较差。所以需要将cost_param的bit1为1时，选择最小的选择率作为总的选择率估算行数比较准确，查询性能较好，优化后的计划如下图所示：

操作步骤 查看阻塞的查询语句及阻塞查询的表、模式信息。 1 2 3 4 5 6 7 8 9 10 11 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、用户信息、查询状态，以及导致阻塞的表、模式信息。 使用如下命令结束相应的会话。其中，139834762094352为线程ID。 1 SELECT PG_TERMINATE_BACKEND(139834762094352); 显示类似如下信息，表示结束会话成功。 PG_TERMINATE_BACKEND ---------------------- t (1 row) 显示类似如下信息，表示用户正在尝试结束当前会话，此时仅会重连会话，而不是结束会话。 FATAL: terminating connection due to administrator command FATAL: terminating connection due to administrator command The connection to the server was lost. Attempting reset: Succeeded. gsql客户端使用PG_TERMINATE_BACKEND函数终止本会话后台线程时，客户端不会退出而是自动重连。

优化后 可将查询可以修改为： 1 SELECT * FROM t1 WHERE NOT EXISTS (SELECT * FROM t2 WHERE t2.c = t1.c); 执行下列语句，查询NOT EXISTS的执行计划： 1 EXPLAIN VERBOSE SELECT * FROM t1 WHERE NOT EXISTS (SELECT 1 FROM t2 WHERE t2.c = t1.c);

优化说明 此优化的核心就是消除子查询。那么从SQL语义出发，可以等价改写SQL为： 1 2 3 4 5 6 select 1, coalesce(a4.c1, 0) from (select count(*) c1, a4.ca_address_sk from customer_address_001 a4 group by a4.ca_address_sk) a4 right join customer_address_001 a on a4.ca_address_sk = a.ca_address_sk;