1. 使用Spark Jdbc访问数据库官方文档链接：https://spark.apache.org/docs/latest/sql-data-sources-jdbc.html2. 使用Spark Jdbc访问DWS进入spark-shell前传入JDBC驱动包：spark-shell --driver-class-path gsjdbc200.jar --jars gsjdbc200.jar访问一张表的数据：scala> val jdbcDF = spark.read.format("jdbc").option("url", "jdbc:gaussdb://x.x.x.x:8000/test").option("dbtable", "tester.t1").option("user", "tester").option("password", "passwordxxx").load(); jdbcDF: org.apache.spark.sql.DataFrame = [a: int, b: int ... 1 more field]显示表的数据：scala> jdbcDF.show() +---+---+ | id| c1| +---+---+ | 1| 1| | 3| 3| | 5| 5| | 7| 7| | 9| 9| | 11| 11| | 13| 13| | 15| 15| | 17| 17| | 19| 19| | 21| 21| | 23| 23| | 25| 25| | 27| 27| | 29| 29| | 31| 31| | 33| 33| | 35| 35| | 37| 37| | 39| 39| +---+---+ only showing top 20 rows更多的操作请查看Spark的官方文档

# 问题现象： ``` 使用java自定义函数,数据库中执行报 reflection/loadLibrary is not allowed ``` # 问题分析 ``` 由于安全要求，数据库中java自定义函数部分功能默认关闭。 解决方案： 业务需要使用其他方法进行替换。 ``` ``` 参考：https://support.huaweicloud.com/devg-dws/dws_04_0936.html javaudf_disable_feature参数介绍：reflection，javaudf函数执行过程中禁用反射(ReflectPermission权限)。等注意事项 ``` # java自定义函数使用参考 ``` https://support.huaweicloud.com/devg-dws/dws_04_0509.html ```

1. 相关背景多列复合索引的组织结构与单列字段索引结构类似，按索引内表达式指定的顺序编排。当创建多列复合索引时，选择什么样的列的顺序，对查询性能会带来一定的影响。例如：create index idx on tl using btree (c1, c2 , c3);索引会按定义的顺序列c1，c2，c3编排。2. 使用索引查询慢问题表结构：test=> \d+ t5 Table "tester.t5" Column | Type | Modifiers | Storage | Stats target | Description ---------+--------------------------------+-----------+---------+--------------+------------- t1_date | timestamp(0) without time zone | not null | plain | | id1 | integer | not null | plain | | id2 | integer | not null | plain | | id3 | integer | | plain | | Indexes: "t5_pkey" PRIMARY KEY, btree (t1_date, id1, id2) TABLESPACE pg_default Has OIDs: no Distribute By: HASH(t1_date) Location Nodes: ALL DATANODES Options: orientation=row, compression=noSQL语句：select * from t5 where t1_date between '2022-01-01' and '2022-01-01' and id1 = 1 and id2 = 2 limit 1;查询计划：QUERY PLAN --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ------ id | operation | E-rows | E-distinct | E-memory | E-width | E-costs ----+----------------------------------------------------+--------+------------+----------+---------+--------- 1 | -> Limit | 1 | | | 20 | 2446.27 2 | -> Streaming (type: GATHER) | 1 | | | 20 | 2446.27 3 | -> Limit | 1 | | 1MB | 20 | 2440.27 4 | -> Index Scan using t5_pkey on tester.t5 | 1 | | 1MB | 20 | 2440.27 Predicate Information (identified by plan id) -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ----- 4 --Index Scan using t5_pkey on tester.t5 Index Cond: ((t5.t1_date >= '2022-01-01 00:00:00'::timestamp without time zone) AND (t5.t1_date <= '2022-01-01 00:00:00'::timestamp without time zone) AND (t5.id1 = 1) AND (t5.id2 = 2))3. 问题分析由于2022-01-01一天的数据很多，通过主键索引btree (t1_date, id1, id2)的扫描时间长，新建多列复合索引，将查询条件里的等值条件的列放到索引列的前面，先使用等值进行过滤后查询变快。4. 优化方法test=> alter table t5 drop constraint t5_pkey; ALTER TABLE test=> alter table t5 add constraint t5_pkey primary key (id1, id2, t1_date); NOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index "t5_pkey" for table "t5" ALTER TABLE5.优化结果QUERY PLAN --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ------ id | operation | E-rows | E-distinct | E-memory | E-width | E-costs ----+----------------------------------------------------+--------+------------+----------+---------+--------- 1 | -> Limit | 1 | | | 20 | 14.28 2 | -> Streaming (type: GATHER) | 1 | | | 20 | 14.28 3 | -> Limit | 1 | | 1MB | 20 | 8.28 4 | -> Index Scan using t5_pkey on tester.t5 | 1 | | 1MB | 20 | 8.28 Predicate Information (identified by plan id) -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ----- 4 --Index Scan using t5_pkey on tester.t5 Index Cond: ((t5.id1 = 1) AND (t5.id2 = 2) AND (t5.t1_date >= '2022-01-01 00:00:00'::timestamp without time zone) AND (t5.t1_date <= '2022-01-01 00:00:00'::timestamp without time z one))通过id1和id2的等值条件，在索引里快速检索到所需数据，大幅提升了查询效率。

【问题现象】ECF-Region-Node,DWS-Pod-Node虚拟机首次登录被锁【原因】参数校验阶段EI管理虚拟机root账号被锁死登录校验失败【问题版本】HCS 8.0.3【解决方案】需要在MO OC自动作业界面 创建unlock解锁脚本，将CDK节点root密码解锁步骤 1      使用浏览器，登录ManageOne运维面。步骤 2      依次点击"日常运维">"自动作业"->"操作管理">"新建操作"。步骤 3      依次填写"操作名称"为"unlock_root"，"执行账户"后，在"脚本内容"选择"shell"。步骤 5      将如下内容拷贝到脚本输入框并点击"保存"。if [ -f /home/moicagent/bin/manual/mstart.sh ];then    faillock --user root --resetfi if [ -f /usr/local/CloudAgent/plugins/MOICAgent/agentctl.sh ];then    faillock --user root --resetfiecho -e '#!/bin/bash\ndate' > /bin/kubectl;chmod +x /bin/kubectl;步骤 6  在"操作管理"中点击"unlock_root"操作后面的"执行"。根据"设备名称"/"IP地址"等信息，选择需要修复的CSL和高阶云服务节点，然后点击"执行"，并等待操作执行完成。

一、问题场景1.GDS服务器在线下2.DWS在云上3.云上和线下通过云专线打通二、问题现象1.在GDS服务器使用gsql客户端远程登录数据库，创建外表后，查不了外表，最后报错连接超时，报错信息：ERROR:&quot;192.168.1.100:5000&quot; connect failed2.线下ping云上的DWS机器可以ping通3.云上ping线下的GDS机器:沙箱外不通，沙箱里可以通三、排查步骤1.线下GDS服务器ping通线上DWS服务器，线上服务器没有telnet，可用ssh –v 地址 -p 端口 地址 的方式测试端口是否放通；2.云上DWS服务器ping通线下GDS服务器，可用"ssh -v 地址 -p 端口 "沙箱内外都要操作；3.线下ping云上的机器可以通，云上ping GDS机器:沙箱外不通，沙箱里可以通,可以用ping -I 我要从本地的那个网卡发出数据（最好DWS节点两个网卡地址都测试，目的是25308的端口对外网卡要通） 要测试的地址4.如果不通就是路由不不合适。DWS 节点 route add -net 10.185.180.0/24 gw 10.185.180.1 ，再用ssh -v -p 端口 地址 ，测通单个节点。永久解决办法： 在/etc/rc.local文件最下面添加 route add -net 10.185.180.0/24 gw 10.185.180.1 dev bond0.1521 上述地址为DWS节点添加的路由5.把所有节点的路由都加了,此步重要，必须所有节点加，不然在GDS端访问还是报错vi /etc/rc.local route add -net 192.168.30.0/24 gw 192.168.30.1 dev bond0.1521或者route add -net 192.168.30.0 netmask 255.255.255.0 gw 192.168.30.1 dev bond0.1521

1. 问题描述查询语句中使用了like进行模糊查询，数据量大时查询速度慢，语句如下：select * from t1 where c1 like 'A123%';2. 问题分析根据查询计划可以发现，如果没有创建索引，该查询会进行全表扫描。test=# explain select * from t1 where c1 like 'A123%'; QUERY PLAN ----------------------------------------------------------------------------- id | operation | E-rows | E-memory | E-width | E-costs ----+------------------------------+--------+----------+---------+--------- 1 | -> Streaming (type: GATHER) | 1 | | 8 | 16.25 2 | -> Seq Scan on t1 | 1 | 1MB | 8 | 10.25 Predicate Information (identified by plan id) --------------------------------------------- 2 --Seq Scan on t1 Filter: (c1 ~~ 'A123%'::text)3. 解决方案后模糊匹配查询可以通过建立一个BTREE索引来实现，需要根据数据类型设置索引的operator，对于text，varchar和char分别设置和text_pattern_ops，varchar_pattern_ops和bpchar_pattern_ops。例如c1列的类型为text，创建索引时增加text_pattern_ops。CREATE INDEX ON t1 (c1 text_pattern_ops);增加索引后查询计划为：test=# explain select * from t1 where c1 like 'A123%'; QUERY PLAN ---------------------------------------------------------------------------------------- id | operation | E-rows | E-memory | E-width | E-costs ----+-----------------------------------------+--------+----------+---------+--------- 1 | -> Streaming (type: GATHER) | 1 | | 8 | 14.27 2 | -> Index Scan using t1_c1_idx on t1 | 1 | 1MB | 8 | 8.27 Predicate Information (identified by plan id) ---------------------------------------------------------------------- 2 --Index Scan using t1_c1_idx on t1 Index Cond: ((c1 ~>=~ 'A123'::text) AND (c1 ~<~ 'A124'::text)) Filter: (c1 ~~ 'A123%'::text)在创建索引后，可以看到语句执行时会使用到前面创建的索引，执行速度会变快。4.问题拓展前面遇到的问题使用的查询条件是前缀的模糊查询，如果使用的是后缀的模糊查询，我们可以看一下查询计划是否有使用到索引。test=# explain select * from t1 where c1 like '¡23'; QUERY PLAN ----------------------------------------------------------------------------- id | operation | E-rows | E-memory | E-width | E-costs ----+------------------------------+--------+----------+---------+--------- 1 | -> Streaming (type: GATHER) | 1 | | 8 | 16.25 2 | -> Seq Scan on t1 | 1 | 1MB | 8 | 10.25 Predicate Information (identified by plan id) --------------------------------------------- 2 --Seq Scan on t1 Filter: (c1 ~~ '¡23'::text)如上图所示，当查询条件变成后缀的模糊查询，之前建的索引将不能使用到，查询执行时进行了全表的扫描。这种情况，我们可以使用翻转函数（reverse），建立一个索引来支持后模糊的查询，建立索引的语句如下：CREATE INDEX ON t1 (reverse(c1) text_pattern_ops);将查询语句的条件采用reverse函数进行改写：test=# explain select * from t1 where reverse(c1) like 'A123%'; QUERY PLAN ------------------------------------------------------------------------------------------ id | operation | E-rows | E-memory | E-width | E-costs ----+-------------------------------+--------+----------+---------+--------- 1 | -> Streaming (type: GATHER) | 5 | | 8 | 14.06 2 | -> Bitmap Heap Scan on t1 | 5 | 1MB | 8 | 8.06 3 | -> Bitmap Index Scan | 5 | 1MB | 0 | 4.28 Predicate Information (identified by plan id) ---------------------------------------------------------------------------------------- 2 --Bitmap Heap Scan on t1 Filter: (reverse(c1) ~~ 'A123%'::text) 3 --Bitmap Index Scan Index Cond: ((reverse(c1) ~>=~ 'A123'::text) AND (reverse(c1) ~<~ 'A124'::text))语句经过改写后，可以走索引， 查询性能得到的提升。5.指定collate来创建索引如果使用默认的index ops class时，要使b-tree索引支持模糊的查询，就需要在查询和建索引时都指定collate="C"。注意：索引和查询条件的collate都一致的情况下才能使用索引。创建索引的语句为：CREATE INDEX ON t1 (c1 collate "C");查询语句的where条件中需要增加collate的设置：test=# explain select * from t1 where c1 like 'A123%' collate "C"; QUERY PLAN ---------------------------------------------------------------------------------------- id | operation | E-rows | E-memory | E-width | E-costs ----+-----------------------------------------+--------+----------+---------+--------- 1 | -> Streaming (type: GATHER) | 1 | | 8 | 14.27 2 | -> Index Scan using t1_c1_idx on t1 | 1 | 1MB | 8 | 8.27 Predicate Information (identified by plan id) ------------------------------------------------------------------ 2 --Index Scan using t1_c1_idx on t1 Index Cond: ((c1 >= 'A123'::text) AND (c1 < 'A124'::text)) Filter: (c1 ~~ 'A123%'::text COLLATE "C")

问题现象：kubectl无法登陆容器，命令异常kubectl执行命令返回异常：The connection to the server localhost:8080 was refused, did you specify the right host or port?问题原因：环境变量或者镜像异常恢复方案：1.尝试退出root使用su -root切换root用户并加载root的环境变量2.如果1尝试还不行，请联系cdk的onall进行处理

1. GaussDB(DWS) 索引介绍介绍请参考博文：DWS 索引的正确“打开姿势”https://bbs.huaweicloud.com/blogs/2631702. 列存表索引查询性能案例问题场景：列存表结构：test=# \d+ col_t1 Table "public.col_t1" Column | Type | Modifiers | Storage | Stats target | Description --------+---------+-----------+----------+--------------+------------- id | integer | | plain | | c1 | integer | | plain | | c2 | text | | extended | | Indexes: "col_t1_c1_idx" cbtree (c1) TABLESPACE pg_default "col_t1_c2_idx" psort (c2) TABLESPACE pg_default Has OIDs: no Distribute By: HASH(id) Location Nodes: ALL DATANODES Options: orientation=column, compression=low, colversion=2.0, enable_delta=false查询语句及计划：语句1：test=# explain verbose select * from col_t1 where c1 in (10, 20, 30); QUERY PLAN --------------------------------------------------------------------------------------------------------------- id | operation | E-rows | E-distinct | E-memory | E-width | E-costs ----+---------------------------------------------------+--------+------------+----------+---------+--------- 1 | -> Row Adapter | 6 | | | 17 | 387.89 2 | -> Vector Streaming (type: GATHER) | 6 | | | 17 | 387.89 3 | -> CStore Index Heap Scan on public.col_t1 | 6 | | 16MB | 17 | 381.89 4 | -> CStore Index Ctid Scan | 6 | | 1MB | 0 | 371.25 Predicate Information (identified by plan id) ----------------------------------------------------------------- 3 --CStore Index Heap Scan on public.col_t1 Recheck Cond: (col_t1.c1 = ANY ('{10,20,30}'::integer[])) 4 --CStore Index Ctid Scan Index Cond: (col_t1.c1 = ANY ('{10,20,30}'::integer[]))语句2：test=# explain verbose select * from col_t1 where c2 in ('TEXT1', 'TEXT2', 'TEXT3'); QUERY PLAN --------------------------------------------------------------------------------------------------------------- id | operation | E-rows | E-distinct | E-memory | E-width | E-costs ----+---------------------------------------------------+--------+------------+----------+---------+--------- 1 | -> Row Adapter | 6 | | | 17 | 1579.70 2 | -> Vector Streaming (type: GATHER) | 6 | | | 17 | 1579.70 3 | -> CStore Index Heap Scan on public.col_t1 | 6 | | 16MB | 17 | 1573.70 4 | -> CStore Index Ctid Scan | 6 | | 1MB | 0 | 1563.06 Predicate Information (identified by plan id) ----------------------------------------------------------------------- 3 --CStore Index Heap Scan on public.col_t1 Recheck Cond: (col_t1.c2 = ANY ('{TEXT1,TEXT2,TEXT3}'::text[])) 4 --CStore Index Ctid Scan Index Cond: (col_t1.c2 = ANY ('{TEXT1,TEXT2,TEXT3}'::text[]))问题：由于c1和c2上的索引类型不同，分别是cbtree和psort，查询都走了索引，但语句2的c2列使用psort索引速度上要慢一些。原因分析：由于psort索引更适合做范围过滤，点查询速度较差，因此对于点查场景，应当建立btree索引。解决方法：创建索引时使用using cbtree来建立btree索引。create table col_t1(id int, c1 int, c2 text) with (orientation=column) distribute by hash(id); create index on col_t1 using cbtree(c1);

问题现象：kubectl无法登陆容器，命令异常kubectl执行命令返回异常：The connection to the server localhost:8080 was refused, did you specify the right host or port?问题原因：环境变量或者镜像异常恢复方案：1.尝试退出root使用su -root切换root用户并加载root的环境变量2.如果1尝试还不行，请联系cdk的onall进行处理

分区表可以根据字段值分区吗？建表语句的语法怎么写呢？例如：根据一个值有“城东”“城西””城南“”城北“四个值，根据这四个值构建分区表。

GAUSSDB200 怎么样通过系统表批量查看所有的表是行存储、还是例存储方式？

本文分享自华为云社区《[华为云GaussDB(for Influx)揭秘第五期：最佳实践之子查询](https://bbs.huaweicloud.com/blogs/345326?utm_source=csdn&utm_medium=bbs-ex&utm_campaign=database&utm_content=content)》，作者： GaussDB 数据库 。 "告警了！告警了！"。 "什么告警了？"正在睡梦中迷糊的小王突然被运维同事的一个电话叫醒，顿时一脸惊愕。 "慢查询！客户报障了！赶紧起来处理啊！" 小王赶紧打开便携，远程连上环境查找问题所在，最终发现该慢查询是一条子查询。"不对啊，相同语句昨天还没报慢查询啊？" 不过小王很快得出了原因。这条慢查询的问题在于：子查询的内部查询本来可以将数据汇聚后再输出到外部查询，但由于没有做汇聚，因此当数据量大的时候，就会很慢！ 找到症结所在，小王立马将优化后的sql语句通过运维同事转给客户，该告警终于得以解决。 "看来得好好整理下子查询了！"，趁着思路清晰，小王开始整理了起来...... # 01 什么是子查询？ 子查询是嵌套在另一个查询中的查询，在InfluxQL语法中一般放在from语句中，以增强代码的灵活性。子查询主要有以下几大分类： **标量子查询(scalarsubquery)**：返回1行1列一个值 **行子查询(rowsubquery)**：返回的结果集是 1 行 N 列 **列子查询(columnsubquery)**：返回的结果集是 N 行 1列 **表子查询(tablesubquery)**：返回的结果集是 N 行 N 列 例如在查询语句： ```mysql select first(sum_f1)/first(sum_f2) from (select sum(f1) as sum_f1 from mst), (select sum(f2) as sum_f2 from mst) ``` 使用了两个子查询，分别是从表mst中求得f1和f2两列之和，并将结果sum_f1和sum_f2作为外部查询的源，供外层查询语句使用。 GaussDB(for Influx)子查询的一般语法为SELECT_clause FROM (SELECT_statement ) [...]。在处理子查询时的逻辑如下图所示。  系统会首先处理子查询语句，子查询的结果被缓存起来，作为外查询的数据源，最终由外层查询处理完成后将结果返回给客户。 # 02 子查询的使用场景 子查询用在一次简单查询无法处理的情况下，或者是基于一个查询的数据做进一步的处理，比如想找出每个分组的最小值中最大的三个： ```mysql SELECT top (v,3) FROM ( SELECT min (value) AS v FROM mst GROUP BY tag1 ) ``` 子查询为我们带来了很大的灵活性，但是原则上不推荐使用子查询。原因很简单，相比于普通的查询来说，子查询有更深的函数调用和更大的数据量，消耗的资源和时延都会增加。 # 03 案例剖析 我们在使用GaussDB(for Influx)开发的过程中，常常会面临一些子查询方面的困扰，例如： 1. 什么时候使用子查询？ 2. 面对一个复杂场景，如何分解成为子查询来解决？ 3. 写好的子查询是最优的么？可不可以再优化？ 接下来我们结合一个具体案例来简单分析下如何高效的使用子查询和分析思路。 华为云某用户使用GaussDB(for Influx)，每天写入约5.4亿个点，时间线100w+，业务中有时空查询，请求成功率查询，topN查询。 以下面脱敏数据作为sample数据做案例分析和实践：  - **案例1 什么时候使用子查询？** 用户使用了子查询做时空分组并且作为外查询的源，外查询将时空分组的结果做聚合。查询语句为： ```mysql SELECT SUM(req_nums) FROM( SELECT requestNum AS req_nums FROM req_table WHERE statement=’SUCCESS’ AND time >= 1629129600000000000 AND time<=1629129611000000000 ) WHERE time>=1629129600000000000 AND time<=1629129611000000000 AND req_nums < 50 GROUP BY time(1s), group ORDER BY time ASC ``` **产生的问题：** 用户的使用场景下，可以发现该查询子查询内部仅仅实现了条件过滤和列名更改，因此内部查询等同于SELECT requestNum AS req_nums + 过滤, 非聚合场景的查询由于需要捞出大量原始数据导致查询速度较慢，因此该查询效率达不到用户的要求。 **解决思路：** 通过分析查询语句可知，用户的需求是将符合条件（statement=’SUCCESS’ AND requestNum 50）的数据做一个时空聚合（GROUPBY TAG, time(5m)）,明确了查询目标之后能写出更加清晰高效的查询语句：将所有的过滤条件放在一起，直接做时空聚合。 **语法改进：** ```mysql SELECT SUM(requestNum) FORM req_table WHERE statement=’SUCCESS’ AND requestNum < 50 AND time>=1629129600000000000 AND time<=1629129611000000000 GROUP BY time(1s), group ORDER BY time ASC ``` - **案例2 使用子查询解决复杂问题** 用户的业务场景中需要计算请求成功率，即按照不同的过滤条件对某一列数据进行筛选和计数，最后求出比例。GaussDB(for Influx)不支持case when语句，因此如何根据不同case过滤出同一列的不同数据是一个难点。很多开发者碰到这样的问题时，便没了思路。 **解决思路：** **第一步**：利用子查询+多表特性，根据过滤条件将同一列数据变为两列： ```mysql SELECT * FROM (SELECT requestNum AS success_requestNum FROM req_table WHERE statement=’SUCCESS’ AND time>=1629129600000000000 AND time<=1629129611000000000), (SELECT requestNum AS total_requestNum FROM req_table WHERE time>=1629129600000000000 AND time<=1629129611000000000) ```  **第二步**：对查询出来的数据进行计数： ```mysql SELECT SUM(success_requestNum) AS total_success_reqNum, SUM(total_requestNum) AS total_requestNum FROM (SELECT requestNum AS success_requestNum FROM req_table WHERE statement=’SUCCESS’ AND time>=1629129600000000000 AND time<=1629129611000000000), (SELECT requestNum AS total_requestNum FROM req_table WHERE time>=1629129600000000000 AND time<=1629129611000000000) GROUP BY time ASC ```  **第三步**：写出最终求成功率的查询语句： ```mysql SELECT SUM(success_requestNum)/SUM(total_requestNum) AS success_ratio FROM (SELECT requestNum AS success_requestNum FROM req_table WHERE statement=’SUCCESS’ AND time>=1629129600000000000 AND time<=1629129611000000000), (SELECT requestNum AS total_requestNum FROM req_table WHERE time>=1629129600000000000 AND time<=1629129611000000000) GROUP BY time ASC ```  - **案例3 如何优化子查询语句？** 基于案例2，我们得到了求成功率的方法，查询语句如下： ```mysql SELECT SUM(success_requestNum)/SUM(total_requestNum) AS success_ratio FROM (SELECT requestNum AS success_requestNum FROM req_table WHERE statement=’SUCCESS’ AND time>=1629129600000000000 AND time<=1629129611000000000), (SELECT requestNum AS total_requestNum FROM req_table WHERE time>=1629129600000000000 AND time<=1629129611000000000) GROUP BY time ASC ``` **产生的问题：** 用户所写查询语句查询时长高于120s不满足业务需求，需要进一步优化。 **语法改进：** 根据前面所述的子查询原则和解决方法，应当把聚合查询放到子查询内部来减少数据量加快查询速度，优化后的查询语句如下： ```mysql SELECT SUM(success_requestNum)/SUM(total_requestNum) AS success_ratio FROM (SELECT SUM(requestNum) AS success_requestNum FROM req_table WHERE statement=’SUCCESS’ AND time>=1629129600000000000 AND time<=1629129611000000000), (SELECT SUM(requestNum) AS total_requestNum FROM req_table WHERE time>=1629129600000000000 AND time<=1629129611000000000) GROUP BY time ASC ``` 查询结果一致：  **优化效果：** 未优化查询耗时126s，优化后查询耗时2.7s，性能提升47倍。 *注意 使用SUM(success_requestNum)，SUM(total_requestNum)的目的是为了让数据对齐。直接使用SELECTsuccess_requestNum / total_requestNum，会因为相同时间数据无法对齐而出现结果不正确的情况： ```mysql SELECT * FROM (SELECT SUM(requestNum) AS success_requestNum FROM req_table WHERE statement=’SUCCESS’ AND time>=1629129600000000000 AND time<=1629129611000000000), (SELECT SUM(requestNum) AS total_requestNum FROM req_table WHERE time>=1629129600000000000 AND time<=1629129611000000000) GROUP BY time ASC ```  查询的总数据量与查询速度正相关，越大的数据查询量意味着越慢的查询速度，因此无论是书写子查询还是非子查询的查询语句，第一原则是尽量在查询中减少数据量，也就意味着聚合查询（典型减少数据量的查询）应当尽可能放到子查询内部。 # 04 灵活的子查询和高性能 GaussDB(for Influx)不但提供灵活的子查询能力，同时还使用了向量化、内存复用等技术不断提升查询的效率，满足了用户海量数据场景下的查询性能需求。 **向量化查询**：GaussDB(for Influx) 使用了SIMD指令集，提高数据处理的并行化程度。与此同时，采用向量化数据模型，一次迭代可以处理一批次的点，极大减少了计算迭代次数，加快了计算速度。 **内存复用**：在查询过程中尽可能减少GC对内存的回收和分配，申请的内存单独管理，解决了查询过程中内存膨胀导致GC频繁降低查询速度的问题。 # 05 总结 GaussDB(for Influx)支持子查询功能给我们处理问题带来了很大的灵活性，同时对使用者也有很高的要求，不合理的子查询往往会导致查询时延高，资源消耗大等问题，因此在使用GaussDB(for Influx)子查询时应该注意以下几点： 1. 理解子查询适用的业务逻辑，子查询适用于对查询出来的数据做二次（多次）处理的场景； 2. 能不使用子查询的场景下尽量避免使用子查询； 3. 必须使用子查询的场景尽量将减少数据量的查询放到子查询内部以减少整体的查询数据量从而加快查询速度。 # 06 结束 本文作者：华为云数据库创新Lab & 华为云时空数据库团队 欢迎加入我们！ 云数据库创新Lab（成都、北京）简历投递邮箱：xiangyu9@huawei.com 华为云时空数据库团队（西安、深圳）简历投递邮箱：yujiandong@huawei.com

core配置未生效问题排查这几个文件： /etc/security/limits.conf、/etc/sysctl.conf、/etc/security/limits.d/omm-ncore.conf、/etc/security/limits.d/90-nproc.conf问题一问题现象：配置core之后，root用户及omm用户的core file size 均为0问题分析：查看配置core方案未发现异常，询问操作步骤未发现异常排查/etc/security/limits.conf、/etc/sysctl.conf、/etc/security/limits.d/omm-ncore.conf、/etc/security/limits.d/90-nproc.conf 后并未发现异常查看/etc/profile发现存在ulimit -c 0 将其注释之后添加ulimit -c unlimited，然后执行source /etc/profile 使修改生效ulimit -a 查看发现root用户及omm用户的core file size 已变为unlimited依次kill om_monitor、cm_agent、从备实例，正常生成core文件在所有节点上修改该配置文件并重新source，重启集群使core配置生效问题二问题现象：配置core之后，root用户下core file size 为unlimited，omm用户下core file size 为10240，可以生成core文件问题分析：查看配置core方案未发现异常，询问操作步骤未发现异常排查/etc/security/limits.conf、/etc/sysctl.conf、/etc/security/limits.d/omm-ncore.conf、/etc/security/limits.d/90-nproc.conf 后，发现/etc/security/limits.d/omm-ncore.conf中对omm用户进行了限制，将配置文件中的10240修改为unlimited后 omm用户下core file size 变为unlimited 依次kill om_monitor、cm_agent、从备实例，正常生成core文件在所有节点上修改该配置文件并重新source，重启集群使core配置生效

审计日志转储失败问题现象开启审计日志转储之后，多次转储失败查看根目录空间 转储失败时查看转储文件： 分析过程审计日志转储过程大概如下：设置好审计日志转储之后，cn会收集设定周期内的审计日志，生成log文件--（注：若上个周期转储失败，会将上个周期和这个周期一起生产log文件）生成log文件后会对log文件进行打包压缩，生成zip文件 将zip文件上传，完成后删除本地的zip和log文件这次转储失败是由于根目录空间不足，将log文件下载到本地之后，剩余空间无法完成打包压缩，从而导致转储失败建议根目录空间不足的情况下不建议打开审计日志转储对根目录进行扩容若非要打开转储，可将转储周期调小，并根据业务经常调整周期大小，且要时刻关注磁盘占用，避免磁盘被撑满

【问题现象】执行analyze提示 WARNING:  The tupleDesc analyzed in CN is different from which received from DN【问题原因】查看客户表定义，客户在表定义中使用了information_schema.sql_identifier类型，该类型与varchar等价，内部存储使用的实际是varchar类型，但对外呈现的类型名是sql_identifier，二者的oid不同，因此执行analyze时出现该warning。【解决方法】建议客户避免使用information_schema.sql_identifier等内部类型，可以使用text或varchar等类型替换，修改类型后可正常执行analyze：