华为云用户手册

分区自动管理 分区管理功能是和表级参数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数据的区域如表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

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

CREATE DATABASE语法格式 1 2 3 4 5 6 7 8 CREATE DATABASE database_name [ [ WITH ] { [ OWNER [=] user_name ] | [ TEMPLATE [=] template ] | [ ENCODING [=] encoding ] | [ LC_COLLATE [=] lc_collate ] | [ LC_CTYPE [=] lc_ctype ] | [ DBCOMPATIBILITY [=] compatibility_type ] | [ CONNECTION LIMIT [=] connlimit ]}[...] ];

什么是湖仓一体？ 虽然数据仓库和 数据湖 的应用场景和架构不同，但它们并不是对立关系。数据仓库存储结构化的数据，适用于快速的BI和决策支撑，而数据湖可以存储任何格式的数据，往往通过挖掘能够发挥出数据的更大作为，因此在一些场景上二者的并存可以给企业带来更多收益。 湖仓一体，又被称为Lake House，其出发点是通过数据仓库和数据湖的打通和融合，让数据流动起来，减少重复建设。Lake House架构最重要的一点，是实现数据仓库和数据湖的数据/元数据无缝打通和自由流动。湖里的“显性价值”数据可以流到仓里，甚至可以直接被数仓使用；而仓里的“隐性价值”数据，也可以流到湖里，低成本长久保存，供未来的数据挖掘使用。

数据智能方案 数据治理中心 DataArts Studio为大型政企客户量身定制跨越孤立系统、感知业务的数据资源智能管理解决方案，实现全域数据入湖，帮助政企客户从多角度、多层次、多粒度挖掘数据价值，实现数据驱动的数字化转型。 数据治理 中心 DataArts Studio 的核心主要是 智能数据湖 FusionInsight，包含数据库、数据仓库、数据湖等各计算引擎平台，提供了数据使能的全套能力，支持数据的采集、汇聚、计算、资产管理、数据开放服务的全生命周期管理。 拥有强大的湖、仓、库引擎技术，比如数据湖敏捷构建、 GaussDB数据库 快速迁移，数仓的实时分析等，对应服务如下： 数据库： 关系型数据库包括：云数据库RDS、云数据库GaussDB(for MySQL)、云数据库GaussDB、云数据库PostgreSQL、云数据库 SQL Server等。 非关系型数据库包括：文档数据库服务DDS、云数据库GeminiDB等。 数据仓库：云数据仓库GaussDB(DWS)。 数据湖\湖仓一体： MapReduce服务 MRS， 数据湖探索 DLI等。 数据治理中心：数据治理中心DataArts Studio。

什么是数据湖？ 在企业内部，数据是一类重要资产已经成为了共识。随着企业的持续发展，数据不断堆积，企业希望把生产经营中的所有相关数据都完整保存下来，进行有效管理与集中治理，挖掘和探索数据价值。 数据湖就是在这种背景下产生的。数据湖是一个集中存储各类结构化和非结构化数据的大型数据仓库，它可以存储来自多个数据源、多种数据类型的原始数据，数据无需经过结构化处理，就可以进行存取、处理、分析和传输。数据湖能帮助企业快速完成异构数据源的联邦分析、挖掘和探索数据价值。 数据湖的本质，是由“数据存储架构+数据处理工具”组成的解决方案。 数据存储架构：要有足够的扩展性和可靠性，可以存储海量的任意类型的数据，包括结构化、半结构化和非结构化数据。 数据处理工具，则分为两大类： 第一类工具，聚焦如何把数据“搬到”湖里。包括定义数据源、制定数据同步策略、移动数据、编制数据目录等。 第二类工具，关注如何对湖中的数据进行分析、挖掘、利用。数据湖需要具备完善的数据管理能力、多样化的数据分析能力、全面的数据生命周期管理能力、安全的数据获取和数据发布能力。如果没有这些数据治理工具，元数据缺失，湖里的数据质量就没法保障，最终会由数据湖变质为数据沼泽。 随着大数据和AI的发展，数据湖中数据的价值逐渐水涨船高，价值被重新定义。数据湖能给企业带来多种能力，例如实现数据的集中式管理，帮助企业构建更多优化后的运营模型，也能为企业提供其他能力，如预测分析、推荐模型等，这些模型能刺激企业能力的后续增长。 对于数据仓库与数据湖的不同之处，可以类比为仓库和湖泊的区别：仓库存储着来自特定来源的货物；而湖泊的水来自河流、溪流和其他来源，并且是原始数据。 表2 数据湖与数据仓库的对比 维度 数据湖 数据仓库 应用场景 可以探索性分析所有类型的数据，包括机器学习、数据发现、特征分析、预测等。 通过历史的结构化数据进行数据分析。 使用成本 起步成本低，后期成本较高。 起步成本高，后期成本较低。 数据质量 包含大量原始数据，使用前需要清洗和标准化处理。 质量高，可作为事实依据。 适用对象 数据科学家、数据开发人员为主。 业务分析师为主。

什么是数据仓库？ 随着数据库的大规模应用，以及信息行业的数据爆炸式的增长。为了研究数据之间的关系，挖掘数据隐藏的价值，人们越来越多的需要使用联机分析处理OLAP（On-Line Analytical Processing）进行数据分析，探究一些深层次的关系和信息。但是不同的数据库之间很难做到数据共享，数据之间的集成与分析也存在非常大的挑战。 为解决企业的数据集成与分析问题，数据仓库之父比尔·恩门于1990年提出数据仓库（Data Warehouse）。数据仓库主要功能是将OLTP经年累月所累积的大量数据，通过数据仓库特有的数据储存架构进行OLAP，最终帮助决策者能快速有效地从大量数据中，分析出有价值的信息，提供决策支持。自从数据仓库出现之后，信息产业就开始从以关系型数据库为基础的运营式系统慢慢向决策支持系统发展。 数据仓库相比数据库，主要有以下两个特点： 数据仓库是面向主题集成的。数据仓库是为了支撑各种业务而建立的，数据来自于分散的操作型数据。因此需要将所需数据从多个异构的数据源中抽取出来，进行加工与集成，按照主题进行重组，最终进入数据仓库。 数据仓库主要用于支撑企业决策分析，所涉及的数据操作主要是数据查询。因此数据仓库通过表结构优化、存储方式优化等方式提高查询速度、降低开销。 表1 数据仓库与数据库的对比 维度 数据仓库 数据库 应用场景 OLAP OLTP 数据来源 多数据源 单数据源 数据标准化 非标准化Schema 高度标准化的静态Schema 数据读取优势 针对读操作进行优化 针对写操作进行优化

什么是数据库？ 数据库是“按照数据结构来组织、存储和管理数据的仓库”。 广义上的数据库，在20世纪60年代已经在计算机中应用了。但这个阶段的数据库结构主要是层次或网状的，且数据和程序之间具备非常强的依赖性，应用较为有限。 现在通常所说的数据库指的是关系型数据库。关系数据库是指采用了关系模型来组织数据的数据库，其以行和列的形式存储数据，具有结构化程度高、独立性强、冗余度低等优点。1970年关系型数据库的诞生，真正彻底把软件中的数据和程序分开来，成为主流计算机系统不可或缺的组成部分。关系型数据库已经成为目前数据库产品中最重要的一员，几乎所有的数据库厂商新出的数据库产品都支持关系型数据库，即使一些非关系数据库产品也几乎都有支持关系数据库的接口。 关系型数据库的主要用于联机事务处理OLTP（On-Line Transaction Processing）主要进行基本的、日常的事务处理，例如银行交易等场景。

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

优化后 测试发现由于两表结果集过大，导致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返回结果。

优化前 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，对应执行计划如下：

建议 推荐使用两个表*的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;

现象描述 1 2 3 4 select 1, (select count(*) from customer_address_001 a4 where a4.ca_address_sk = a.ca_address_sk) as GZ CS from customer_address_001 a; 此SQL性能较差，查看发现执行计划中存在SubPlan，引用SubPlan结果的算子可能需要反复的调用获取这个SubPlan的值，即SubPlan以下的结果要重复执行很多次。具体如下：

统计信息调优介绍 GaussDB(DWS)是基于代价估算生成的最优执行计划。优化器需要根据ANALYZE收集的统计信息行数估算和代价估算，因此统计信息对优化器行数估算和代价估算起着至关重要的作用。通过ANALYZE收集全局统计信息，主要包括：pg_class表中的relpages和reltuples；pg_statistic表中的stadistinct、stanullfrac、stanumbersN、stavaluesN、histogram_bounds等。

示例 创建表t1、t2、t3： 1 2 3 create table t1(a1 int,b1 int,c1 int,d1 int); create table t2(a2 int,b2 int,c2 int,d2 int); create table t3(a3 int,b3 int,c3 int,d3 int); 原语句为： 1 explain select * from t3, (select a1,b2,c1,d2 from t1,t2 where t1.a1=t2.a2) s1 where t3.b3=s1.b2; 上述查询中，可以使用以下两种方式禁止子查询s1进行提升： 方式一： 1 explain select /*+ no merge(s1) */ * from t3, (select a1,b2,c1,d2 from t1,t2 where t1.a1=t2.a2) s1 where t3.b3=s1.b2; 方式二： 1 explain select * from t3, (select /*+ no merge */ a1,b2,c1,d2 from t1,t2 where t1.a1=t2.a2) s1 where t3.b3=s1.b2; 提升后效果：