【免费试用】什么？听说你想免费试用GaussDB(DWS)？安排！！！  NEW     【看直播，送福利】数仓索引的正确打开姿势，互动赢取超多好礼，价值3500元DWS免费试用等你来拿~  NEW      【妙笔生花有奖征文】——我的华为云数仓之旅   HOT       DWS全技能课程，带您逐梦大时代！参与打卡互动，超多好礼等您拿！  荐  往期活动汇总：活动主题活动时间活动状态零距离接触国产旗舰数据仓库DWS2020年6月11日已结束参与GaussDB   for DWS公众号内容策划，千元大奖等你拿！2020年6月16日已结束疫情一码通背后的超大数据仓库设计2020年7月2日已结束DevRun开发者沙龙-大厂面试必备：PB级数据仓库性能调优2020年7月17日已结束DevRun开发者沙龙 -   数仓安全灵魂三问2020年7月21日已结束“绿波带”，华为云数仓给您开绿灯2020年8月4日已结束解密PB级数据仓库底层存储核心机制2020年8月25日已结束【12·12会员节-GaussDB】动手设计心仪“对象”2020年12月10日已结束PB级分布式数仓GaussDB(DWS)性能调优黑科技2020年10月20日已结束玩转PB级数仓深度调优之依“计”行事2020年11月19日已结束“2020华为数智金融论坛”成功举办，金融界精英共话行业未来2020年12月10日已结束程序猿的世界没有单身汪，数仓界达芬奇带您手动设计心仪对象2020年12月22日已结束免费学习大师课，打卡互动赢好礼~2021年1月27日已结束数仓性能调优必读，带你进阶为性能调优高手2021年2月20日已结束【推荐阅读】【最新活动汇总】DWS活动火热进行中，互动好礼送不停（持续更新中）  HOT  【博文汇总】GaussDB(DWS)博文汇总1，欢迎大家交流探讨~（持续更新中）【维护宝典汇总】GaussDB(DWS)维护宝典汇总贴1，欢迎大家交流探讨（持续更新中）【项目实践汇总】GaussDB(DWS)项目实践汇总贴，欢迎大家交流探讨（持续更新中）【DevRun直播汇总】GaussDB(DWS)黑科技直播汇总，欢迎大家交流学习（持续更新中）【培训视频汇总】GaussDB(DWS) 培训视频汇总,欢迎大家交流学习（持续更新中）扫码关注我哦，我在这里↓↓↓如果您还想参加其他活动，欢迎评论区留言告诉我们哦~

集群开启“历史TOPSQL”对正在运行的集群性能有哪些影响？

因为gds无法加载二进制类型，一般情况会使用encode和decode两个函数来实现gds导出和加载bytea类型数据。但实践后发现，若长度较长，encode函数base64转码的结果，会存在换行的情况。这里面存在一个"+"号，说明换行了。在这样的情况下，导出的数据就会有换行的情况。因此需要将换行替换，用如下的SQL:select replace(encode('abcdefghijkl123mkldjsfn023r09fdsjfdfdafdjodfjadfnvdanionq9fenw','base64'),E'\x0A','');这样就没有换行了。经测试，对换行与不换行的base64结果，进行decode函数解码，结果都是一样的。因此这个不会对在GaussDB(DWS)之间的bytea导入导出产生影响后续查询发现，这个是因为GaussDB(DWS)沿用了postgres的做法，pg的encode结果就是存在换行的情况，而换行的规则源于RFC 822规定。若源于这个规定，那总体来说GaussDB(DWS)对encode的结果换行是没有必要的，这样会使与其他数据库对接二进制数据对接的时候出现问题

1、升级Q:FIM界面上查看版本为C80SPC212，实际当前数据库版本是多少？A:后台以omm用户登录主OMS节点。执行sh ${BIGDATA_HOME}/om-server/om/sbin/queryVersion.sh查看MPPDB对应部件包版本。Q:6.5.1和8.0.0.1版本的区别，做了哪些改动？A:可参考8.0 大颗粒特性汇总材料或相应版本的版本说明书。Q:6.5.1升级到8.0.0.1大概需要多长时间？A:现网变更考虑异常处理时间buffer，一般申请时间窗按一次大版本升级不少于8h，一次补丁不少于4h。Q:6.5.1升级到8.0.0.1配套客户端是否需要升级？A:跨大版本升级时原则上客户端也需要配套升级，如果确实无法同时升级，可先继续使用，但需提前准备好客户端软件包，一旦出现使用低版本客户端导致的问题，要及时升级客户端。Q:C80SPC200的版本是否能升级到8.0.0.2？A:首先确认数据库版本到底是C80SPC200还是C80SPC300，确认方法如下：后台以omm用户登录主OMS节点。执行sh ${BIGDATA_HOME}/om-server/om/sbin/queryVersion.sh查看MPPDB对应部件包版本。根据确认结果升级路径如下：C80SPC200->C80SPC300->8.0.0.2C80SPC300->8.0.0.22、扩容Q:扩容最少需扩多少个节点？A:假设单节点主dn数为N，则推荐新扩容节点数>= (N+1)，因为这样在发生节点故障时该节点上主dn倒换到同一个安全内其它节点时能保证一个节点最多只增加一个主dn，能最大限度降低对其它节点压力。Q:新扩节点硬件配置是否需要与老节点一致？A:新节点cpu、内存、磁盘等硬件配置需要与老节点一致或高于老节点配置，否则新扩进来的低配机器将成为整个集群的瓶颈。Q:新扩容节点的os版本是否需要与老节点一致？A:新节点的os版本需要与老节点os版本在同一个兼容列表中，os兼容列表可查阅相应版本的产品文档。Q:节点数据盘使用率已达80%，是否影响扩容？A:80%已处于较高水位，需收集集群具体表信息后具体分析评估扩容风险及方案。按现网实施经验，一般数据盘使用率达70%则需要考虑进行扩容。Q:扩容节点数超过license容量限制，能否直接扩容？A:不能，需要先导入容量足够的新license然后再进行扩容。本文转载于华为云数仓GaussDB(DWS)公众号。

【功能模块】【操作步骤&问题现象】安装的是单机manager, 这是什么原因，【截图信息】【日志信息】（可选，上传日志内容或者附件）

DROP SERVER IF EXISTS hdfs_server CASCADE;CREATE SERVER hdfs_server FOREIGN DATA WRAPPER HDFS_FDW OPTIONS (TYPE 'hdfs', ADDRESS '@hdfshostname@:@hdfsport@',HDFSCFGPATH '@hdfscfgpath@');-- create t_base, include all the fields supportsCREATE TABLE t_base (       c_distkey         INT,       c_tinyint         TINYINT,       c_smallint        SMALLINT,       c_int             INTEGER,       c_bigint          BIGINT,       c_varchar         VARCHAR,       c_varchar2        VARCHAR2,       c_char            CHAR(30),       c_text            TEXT,       c_numeric         NUMERIC,       c_decimal         DECIMAL,       c_timestamp     TIMESTAMP WITHOUT TIME ZONE,       c_boolean         BOOLEAN,       c_real            REAL,       c_double          DOUBLE PRECISION,       c_bit             CLOB) DISTRIBUTE BY HASH(c_distkey);-- insert into filedINSERT INTO t_base VALUES(0, 0,0,0,0, VARCHAR'00000000', VARCHAR2'00000000', CHAR '0', TEXT'00000000', 0.1111, 0.11111, TIMESTAMP'2015-01-01 00:00:00', TRUE, 0.11111, 0.11111, CLOB'00000000');INSERT INTO t_base VALUES(1, 1,1,1,1, VARCHAR'11111111', VARCHAR2'11111111', CHAR '1', TEXT'11111111', 1.1111, 1.11111, TIMESTAMP'2015-01-01 00:01:01', TRUE, 1.11111, 1.11111, CLOB'11111111');INSERT INTO t_base VALUES(2, 2,2,2,2, VARCHAR'22222222', VARCHAR2'22222222', CHAR '2', TEXT'22222222', 2.1111, 2.11111, TIMESTAMP'2015-01-02 00:02:02', TRUE, 2.11111, 2.11111, CLOB'22222222');INSERT INTO t_base VALUES(3, 3,3,3,3, VARCHAR'33333333', VARCHAR2'33333333', CHAR '3', TEXT'33333333', 3.1111, 3.11111, TIMESTAMP'2015-01-03 00:03:03', TRUE, 3.11111, 3.11111, CLOB'33333333');INSERT INTO t_base VALUES(4, 4,4,4,4, VARCHAR'44444444', VARCHAR2'44444444', CHAR '4', TEXT'44444444', 4.1111, 4.11111, TIMESTAMP'2015-01-04 00:04:04', TRUE, 4.11111, 4.11111, CLOB'44444444');INSERT INTO t_base VALUES(5, 5,5,5,5, VARCHAR'55555555', VARCHAR2'55555555', CHAR '5', TEXT'55555555', 5.1111, 5.11111, TIMESTAMP'2015-01-05 00:05:05', TRUE, 5.11111, 5.11111, CLOB'55555555');INSERT INTO t_base VALUES(6, 6,6,6,6, VARCHAR'66666666', VARCHAR2'66666666', CHAR '6', TEXT'66666666', 6.1111, 6.11111, TIMESTAMP'2015-01-06 00:06:06', TRUE, 6.11111, 6.11111, CLOB'66666666');INSERT INTO t_base VALUES(7, 7,7,7,7, VARCHAR'77777777', VARCHAR2'77777777', CHAR '7', TEXT'77777777', 7.1111, 7.11111, TIMESTAMP'2015-01-07 00:07:07', TRUE, 7.11111, 7.11111, CLOB'77777777');INSERT INTO t_base VALUES(8, 8,8,8,8, VARCHAR'88888888', VARCHAR2'88888888', CHAR '8', TEXT'88888888', 8.1111, 8.11111, TIMESTAMP'2015-01-08 00:08:08', TRUE, 8.11111, 8.11111, CLOB'88888888');INSERT INTO t_base VALUES(9, 9,9,9,9, VARCHAR'99999999', VARCHAR2'99999999', CHAR '9', TEXT'99999999', 9.1111, 9.11111, TIMESTAMP'2015-01-09 00:09:09', TRUE, 9.11111, 9.11111, CLOB'99999999');-- Scenario 1 different column type exportCREATE FOREIGN TABLE t_base_wo (       c_distkey         INT,       c_tinyint         SMALLINT,       c_smallint        SMALLINT,       c_int             INTEGER,       c_bigint          BIGINT,       c_varchar         VARCHAR,       c_varchar2        VARCHAR2,       c_char            CHAR(30),       c_text            TEXT,       c_numeric         NUMERIC,       c_decimal         DECIMAL,       c_timestamp     TIMESTAMP WITHOUT TIME ZONE,       c_boolean         BOOLEAN,       c_real            REAL,       c_double          DOUBLE PRECISION,       c_bit             CLOB) SERVER hdfs_server OPTIONS (   FOLDERNAME '/hdfs_orc_check/t_base_wo/',   FORMAT 'orc',   ENCODING 'utf8')WRITE ONLY;CREATE FOREIGN TABLE t_base_ro (       c_distkey         INT,       c_tinyint         SMALLINT,       c_smallint        SMALLINT,       c_int             INTEGER,       c_bigint          BIGINT,       c_varchar         VARCHAR,       c_varchar2        VARCHAR2,       c_char            CHAR(30),       c_text            TEXT,       c_numeric         NUMERIC,       c_decimal         DECIMAL,       c_timestamp     TIMESTAMP WITHOUT TIME ZONE,       c_boolean         BOOLEAN,       c_real            REAL,       c_double          DOUBLE PRECISION,       c_bit             CLOB) SERVER hdfs_server OPTIONS (   foldername '/hdfs_orc_check/t_base_wo/',   format 'orc',   encoding 'utf8')READ ONLY DISTRIBUTE BY REPLICATION;INSERT INTO t_base_wo SELECT * FROM t_base;SELECT * FROM t_base MINUS SELECT * FROM t_base_ro;SELECT * FROM t_base_ro MINUS SELECT * FROM t_base;DROP FOREIGN TABLE t_base_wo;DROP FOREIGN TABLE t_base_ro;

【版本】DWS 8.0.11、DWS这个的元数据信息都是存在什么地方的呢？ HDFS不能存储太多的小文件是因为元数据信息都存储在NameNode上，DWS为什么没有小文件这样的说法2、DWS表数据存储到硬盘上是怎么样存储的，我记得Oracle是表空间然后表对应建到表空间下然后表空间建到硬盘上，不知道咱们DWS是咋存表数据的。3、DWS 从C80升级到8.X支持滚动升级吗？目前数据量40TB 大约要升级多久

MPPDB备cmserver的主机IP地址，该地址必须是集群中存在的IP地址，且需要配置在业务平面，CMServer与GTMServer部署节点互为主备，建议coordinator不部署在这两个节点上。集群运行过程中，不允许调整CMServer、GTMServer所在节点到其他节点。LLD配置规划工具-集群参数配置 中针对CMS和GTM要求是互为主备的，这样要求的依据是啥？如果不这样配置会有什么问题？

【功能模块】性能调优【操作步骤&问题现象】1、 分布存储和并发查询是高斯A(DWS)数据库的主要优势，也是它的最需要调优的点，网络Stream可能是超过其他资源问题的最大问题,  DWS是否有相关的工具或界面可以监测到最大的或最可疑的网络流量 ，从而逐步定位出关联的SQL,  哪怕是多个SQL"合作"导致的，应该总有一个最耗网络资源的  ?        2、我们有同事总结了一些思路,  看下可行性及难点  ： a.  查看流量大的网卡 (可能是每台主机) b.  查看这个网卡下的哪个端口 c.  查看流量大的端口上的进程  d.  通过进程找到对应的轻量级的线程号 e.  通过 pgxc_comm_client_info 查询轻量级线程号，找到对应的 tid , 通过tid 找到对应的session .   线程可能会比较多，到线程可能没法看到网络消耗了，只能看到cpu time消耗 ,  这个可能与最初的找网络流量消耗不匹配。 涉及到多个DN , CN 上的线程，到底算一个，还是算总体消耗(一个session的总体)，是个问题。   【截图信息】【日志信息】（可选，上传日志内容或者附件）

PIVOT/UNPIVOT 语法转换如下：1、 TD转GaussDB(DWS)行列转换的改写SQLa)         PIVOT使用case when改写b)         UNPIVOT使用unnest ARRAY改写c)         TD_UNPIVOT（语法存在差异），类似改写2、  具体案例a)        PIVOT使用case when改写TDGaussDB(DWS)SELECT *  FROM star1 PIVOT   (      SUM(sales) AS ss1,      SUM(cogs) AS sc       FOR (yr, qtr)      IN (          (2001, 'Q1'),          (2001, 'Q2'),          (2001, 'Q3'),          (2001, 'Q4')      )  )tmp; SELECT *  FROM  (      SELECT           country,          state,          sum(CASE WHEN yr = 2001 AND qtr = 'Q1' THEN sales   END) as "2001_Q1_ss1",          sum(CASE WHEN yr = 2001 AND qtr = 'Q1' THEN cogs   END) as "2001_Q1_sc",          sum(CASE WHEN yr = 2001 AND qtr = 'Q2' THEN sales   END) as "2001_Q2_ss1",          sum(CASE WHEN yr = 2001 AND qtr = 'Q2' THEN cogs   END) as "2001_Q2_sc",          sum(CASE WHEN yr = 2001 AND qtr = 'Q3' THEN sales   END) as "2001_Q3_ss1",          sum(CASE WHEN yr = 2001 AND qtr = 'Q3' THEN cogs   END) as "2001_Q3_sc",          sum(CASE WHEN yr = 2001 AND qtr = 'Q4' THEN sales   END) as "2001_Q4_ss1",          sum(CASE WHEN yr = 2001 AND qtr = 'Q4' THEN cogs   END) as "2001_Q4_sc"      FROM star1       WHERE (yr, qtr) IN ((2001, 'Q1'),(2001, 'Q2'),(2001,   'Q3'),(2001, 'Q4'))      GROUP BY country, state  ) tmp; b)         UNPIVOT使用unnest ARRAY改写TDGaussDB(DWS)SELECT *  FROM star1p UNPIVOT  (      (sales,cogs) FOR yr_qtr IN      (          (Q101Sales, Q101Cogs) AS 'Q101',          (Q201Sales, Q201Cogs) AS 'Q201',          (Q301Sales, Q301Cogs) AS 'Q301'      )  ) tmp;SELECT *  FROM  (      SELECT           *      FROM       (          SELECT               country,              state,              unnest(ARRAY['Q101',      'Q201',    'Q301']) AS yr_qtr,              unnest(ARRAY[Q101Sales, Q201Sales,   Q301Sales]) AS sales,              unnest(ARRAY[Q101Cogs,    Q201Cogs,  Q301Cogs]) AS Cogs          FROM star1p      )      WHERE sales IS NOT NULL AND Cogs IS NOT NULL  )tmp;目前TD UNPIVOT默认不带参数，即默认“UNPIVOT EXCLUDE   NULLS”行为，不是“UNPIVOT   INCLUDE NULLS”行为 c)         TD_UNPIVOT使用unnest ARRAY改写TDGaussDB(DWS)SELECT *  FROM TD_UNPIVOT  (ON( SELECT * FROM star1p)USINGVALUE_COLUMNS(sales)UNPIVOT_COLUMN(‘yr_qtr’)Column_list(‘Q101Sales’,’ Q201Sales’,’ Q301Sales’)Column_alias_list(‘Q101',      'Q201',    'Q301')   ) tmp;SELECT *  FROM  (      SELECT           *      FROM       (          SELECT               country,              state,              unnest(ARRAY['Q101',      'Q201',    'Q301']) AS yr_qtr,              unnest(ARRAY[Q101Sales, Q201Sales,   Q301Sales]) AS sales          FROM star1p      )      WHERE sales IS NOT NULL  )tmp; 

1、背景LBS（Location Based Service，基于位置的服务）有非常广泛的应用场景，最常见的应用就是POI（Point of Interest）的查询，例如用户查找附近的人，附近的餐厅，附近的外卖商家等等。LBS的实现需要数据库存储地理位置信息，开源Redis是一个功能强、效率高、使用方便的缓存数据库，实现了地理位置存储的功能，可以用于LBS的数据存储。开源Redis 3.2以上版本的Geo功能支持了地理位置信息存储管理，但是内存限制导致没有大规模应用。GaussDB(for Redis)（下文简称高斯Redis）兼容开源Redis的Geo功能，使用磁盘替代内存，突破了开源Redis的内存限制，可以完美解决Geo的大规模应用问题。2、开源Redis Geo介绍Redis的Geo功能支持如下 6 个 Geo 的相关操作：(1) geoadd：添加某个地理位置的坐标。(2) geopos：获取某个地理位置的坐标。(3) geodist：获取两个地理位置的距离。(4)  geohash：获取某个地理位置的geohash值。(5)  georadius：根据给定地理位置坐标获取指定范围内的地理位置集合。(6)   georadiusbymember：根据给定地理位置获取指定范围内的地理位置集合。Redis Geo功能的空间索引采用 GeoHash 原理，配合zset集合存储，查询效率接近 log(N)。3、为什么开源Redis Geo没有广泛应用？存储地理位置信息的应用非常广泛，而开源Redis Geo功能也可以存储地理位置信息，并且查询效率高，为什么没有得到大规模的应用呢？分析存储地理位置信息的场景，都有如下特点：1)数据量大大部分场景存储地理位置信息的数据量都是TB级以上的，开源Redis的数据全部存放在内存中，节点的内存大小固定，要支持大数据量的地理位置信息存储，必须增加节点数，这会造成成本过高、大集群维护困难等问题。2)数据持续增长随着用户的增长，地理位置信息的数据也在持续增长，要求底层存储能够无损扩容。但开源Redis扩容需要重新划分hash槽进行数据迁移，必定会影响业务。3)高并发读写开源Redis主从模式下只有主节点可写，主节点高并发数据写入、高并发数据读出，写入速度过高容易造成主从堆积，数据丢失。除此之外，还需要考虑备份恢复，数据一致性，扩容，高可用等数据库系统能力。1) 备份恢复开源Redis提供RDB和AOF方式备份数据，但当数据规模大时，RDB方式恢复的数据一致性和完整性较差，AOF方式数据恢复的效率低。2) 数据一致性开源Redis的主从采用异步复制，会出现数据不一致的情况。3) 高可用开源Redis如果同时挂掉一对主从节点，部分数据将不可用，容错能力弱。4、高斯Redis为什么合适？高斯Redis基于华为自研分布式存储系统DFV，支持PB级大规模的数据存储。解决了开源Redis高成本、存储数据量小、数据不一致等问题，具有秒扩容、超可用、强一致、低成本、自动备份、抗写能力强的优势。5、适用场景高斯Redis Geo功能适用于数据量大、读写频繁的场景。在外卖平台、点评平台、找房平台中，餐馆的数据、外卖骑手的数据、用户的数据、房源的数据这些数据随着用户增长，数据量过亿，对应的地理位置信息的数据量可到数TB级别，正是高斯Redis适用的场景。下面介绍在不同场景中Geo功能的应用。5.1外卖场景：（1）用户下完外卖订单后，使用geoadd命令加入骑手的位置。（2）使用geopos命令，用户可获得骑手的具体位置。（3）使用georadius/ georadiusbymember命令骑手查看附近可配送的订单。（4）使用geodist命令用户可获得骑手的距离。5.2点评场景：（1）新的店铺加入点评平台，使用geoadd命令，添加新店铺的位置。（2）使用geopos命令，用户获得店铺的具体位置。（3）使用geodist命令，用户可获得与店铺的距离。（4）使用georadius/ georadiusbymember，用户可查找距离500米范围的店铺。5.3找房场景：（1）新的房源加入房源平台中，使用geoadd命令，添加新房源的位置。（2）使用geopos命令，用户可获得房源的具体位置。（3）使用geodist命令，用户可获得与房源的距离。（4）使用georadius/ georadiusbymember命令，用户查找附近1km范围内的房源。6、总结开源Redis的Geo功能查询效率高，但存在存储容量小、抗写能力弱、可用性差等明显缺点，导致了其Geo功能一直没有广泛应用。高斯Redis突破了开源Redis的内存限制，以高性能磁盘存储数据，具有秒扩容、超可用、强一致、低成本、自动备份、抗写能力强的特点，因此高斯Redis适用于大量地理位置信息存储的场景。7、结束本文作者：华为云高斯Redis团队。杭州西安深圳简历投递：yuwenlong4@huawei.com更多技术文章，关注高斯Redis官方博客：https://bbs.huaweicloud.com/community/usersnew/id_1614151726110813 PS：值此开年采购季之际，企业新用户购买GaussDB (for Redis)4U16G任意存储规格，内存可享3个月3折。另外还有多款云数据库包年低至2.7折，0门槛抽千元大奖、新购满额送华为手机P40 Pro 5G等多重福利，链接：https://activity.huaweicloud.com/dbs_Promotion/index.html

【功能模块】存储【操作步骤&问题现象】部署DWS，组RAID后多一块盘，能直接在RAID卡中配置温备盘吗【截图信息】【日志信息】（可选，上传日志内容或者附件）

从oracle导出来的数据文件格式是dmp的，想使用GDS将数据导入到GaussDB，但是GDS只支持CSV、TEXT、FIXED的数据格式，有什么好的办法吗？

【功能模块】压缩功能。 【操作步骤&问题现象】1、 高斯DB在CREATE TABLE的时候，无法对每个字段设置不同的压缩算法及级别(只能表级，Greenplum可以字段级设置)，是否高斯A会自动对不同类型的字段使用不同的最佳压缩算法 ？  2、 看过一些论文，列存库很大的一个优势，是延迟物化，很多场景下，压缩的数据是可以参与计算，最后才解压返回真实数据给用户，节省了I/O和内存资源，咨询高斯专家， 这个特性在高斯A是没有的，必须解压后参与计算 ，这个是否会作为后续的方向 ？    【截图信息】【日志信息】（可选，上传日志内容或者附件）

根据数据库的SQL执行机制以及大量的实践总结发现：通过一定的规则调整SQL语句， 在保证结果正确的基础上，能够提高SQL执行效率。1、 使用union all代替union union在合并两个集合时会执行去重操作，而union all则直接将两个结果集合并、 不执行去重。执行去重会消耗大量的时间，因此，在一些实际应用场景中，如果 通过业务逻辑已确认两个集合不存在重叠，可用union all替代union以便提升性 能。2、 join列增加非空过滤条件 若join列上的NULL值较多，则可以加上is not null过滤条件，以实现数据的提前过 滤，提高join效率。3、 not in转not exists not in语句需要使用nestloop anti join来实现，而not exists则可以通过hash anti join来实现。在join列不存在null值的情况下，not exists和not in等价。因此在确 保没有null值时，可以通过将not in转换为not exists，通过生成hash join来提升 查询效率。如下所示，如果t2.d2字段中没有null值(t2.d2字段在表定义中not null)查询可以修 改为 SELECT * FROM t1 WHERE  NOT EXISTS (SELECT * FROM t2 WHERE t1.c1=t2.d2);产生的计划如下：● 选择hashagg。 查询中GROUP BY语句如果生成了groupagg+sort的plan性能会比较差，可以通过 加大work_mem的方法生成hashagg的plan，因为不用排序而提高性能。 ● 尝试将函数替换为case语句。 GaussDB A函数调用性能较低，如果出现过多的函数调用导致性能下降很多，可 以根据情况把可下推函数的函数改成CASE表达式。● 避免对索引使用函数或表达式运算。 对索引使用函数或表达式运算会停止使用索引转而执行全表扫描。● 尽量避免在where子句中使用!=或<>操作符、null值判断、or连接、参数隐式转 换。● 对复杂SQL语句进行拆分。 对于过于复杂并且不易通过以上方法调整性能的SQL可以考虑拆分的方法，把SQL 中某一部分拆分成独立的SQL并把执行结果存入临时表，拆分常见的场景包括但 不限于： – 作业中多个SQL有同样的子查询，并且子查询数据量较大。 – Plan cost计算不准，导致子查询hash bucket太小，比如实际数据1000W 行，hash bucket只有1000。 – 函数（如substr,to_number）导致大数据量子查询选择度计算不准。 – 多DN环境下对大表做broadcast的子查询。