华为云用户手册

plan_cache_mode 参数说明：标识在prepare语句中，选择生成执行计划的策略。 参数类型：USERSET 取值范围：枚举类型 auto表示按照默认的方式选择custom plan或者generic plan。 force_generic_plan表示强制走generic plan。 force_custom_plan表示强制走custom plan。 此参数只对prepare语句生效，一般用在prepare语句中参数化字段存在比较严重的数据倾斜的场景下。 custom plan是指对于preapre语句，在执行execute的时候，把execute语句中的参数嵌套到语句之后生成的计划。custom plan会根据execute语句中具体的参数生成计划，这种方案的优点是每次都按照具体的参数生成优选计划，执行性能比较好；缺点是每次执行前都需要重新生成计划，存在大量的重复的优化器开销。 generic plan是指对于preapre语句生成计划，该计划策略会在执行execute语句的时候把参数bind到plan中，然后执行计划。这种方案的优点是每次执行可以省去重复的优化器开销；缺点是当bind参数字段上数据存在倾斜时该计划可能不是最优的，部分bind参数场景下执行性能较差。 默认值：auto

hashjoin_spill_strategy 参数说明：选择hashjoin下盘策略。（该参数8.1.2及以上版本支持） 参数类型：USERSET 取值范围：整型，0～4 0：当内表较大，并且多次下盘无法分开时，尝试外表是否可以放到数据库可用内存建立哈希表。如果内外表均很大，执行NestLoop。 1：当内表较大，并且多次下盘无法分开时，尝试外表是否可以放到数据库可用内存建立哈希表。如果内外表均很大，强制执行HashJoin。 2：当内表较大，并且多次下盘无法分开时，强制执行HashJoin。 3：当内表较大，并且多次下盘无法分开时，尝试外表是否可以放到数据库可用内存建立哈希表。如果内外表均很大，则报错。 4：当内表较大，并且多次下盘无法分开时，则报错。 此参数只对向量化HashJoin生效。 对于数据distinct值很小且数据量很大的场景，可能出现无法下盘导致使用内存过大产生内存不受控的问题。 取值0时通过尝试内外表交换或者Nestloop可以避免出现此类内存不受控问题。 执行Nestloop可能造成某些场景性能劣化。 取值0对向量化Full Join不生效，行为与取值1相同。只尝试外表是否可建立哈希表，不执行NestLoop。 默认值：0

max_streams_per_query 参数说明：控制查询计划中Stream节点的数目。（该参数仅8.1.3.200及以上集群版本支持） 参数类型：SUSET 取值范围：整型，-1～10000 -1，表示查询计划中Stream节点数目无限制。 0~10000，表示查询计划中Stream节点数目超过设定值后报错，查询计划不会被执行。 此参数只控制DN上的Stream节点，不考虑CN上的Gather节点。 此参数不影响Explain查询计划，但是对Explain analyze和Explain performance有影响。 默认值：-1

enable_sonic_optspill 参数说明：标识是否优化sonic场景下Hash Join或者Hash Agg的下盘文件个数。仅在enable_sonic_hashjoin或者 enable_sonic_hashagg开启情况下生效。 参数类型：USERSET 取值范围：布尔型 on表示开启下盘文件数优化。 off表示关闭下盘文件数优化。 满足sonic条件下的Hash Join或者Hash Agg算子，在关闭此参数（设置为off）时每列会产生1个下盘文件。开启此参数（设置为on）时如果不同列数据类型相似，只会有1个下盘文件（最多5个文件）。 默认值：on

query_dop 参数说明：用户自定义的查询并行度。 参数类型：USERSET 取值范围：整型，-64-64 [1,64]：打开固定SMP功能，系统会使用固定并行度。 0：打开SMP自适应功能，系统会根据资源情况和计划特征动态为每个查询选取[1，8]之间（x86平台），[1，64]之间（鲲鹏平台）的最优的并行度。 [-64，-1]：打开SMP自适应功能，并限制自适应选取的最大并行度。 对于短查询为主的TP类业务中，如果不能通过CN轻量化或下发语句进行业务的调优，则生成SMP计划的时间较长，建议设置query_dop=1。对于AP类复杂语句的场景，建议设置query_dop=0。 在开启并行查询后，请保证系统CPU、内存、网络、I/O等资源充足，以达到良好效果。 为了避免用户设置不合理的过大值造成性能劣化，系统会计算出该DN可用最大CPU核数，并以此来作为query_dop的上限。如果用户设置query_dop超过4并且同时超过该上限，那么系统会重置query_dop为该上限值。 默认值：1

cursor_tuple_fraction 参数说明：优化器估计游标获取行数在总行数中的占比。 参数类型：USERSET 取值范围：浮点型，0.0～1.0。 比默认值小的值与使用 “fast start” 为游标规划的值相偏离，从而使得前几行恢复的很快而抓取全部的行需要很长的时间。比默认值大的值加大了总的估计的时间。在最大的值1.0处，像正常的查询一样规划游标，只考虑总的估计时间和传送第一行的时间。 默认值：0.1

codegen_strategy 参数说明：标识在表达式codegen化过程中所使用的代码生成优化策略。 参数类型：USERSET 取值范围：枚举类型 partial表示当所计算表达式中即使包含部分未被codegen化的函数时，仍可借助表达式全codegen框架调用LLVM动态编译优化策略。 pure表示当所计算表达式整体可被codegen化时，才考虑调用LLVM动态编译优化策略。 在开启代码生成优化会导致查询性能下降的场景下可以设置此参数为pure，其他场景下建议不改变此参数的默认值partial。 默认值：partial

enable_sonic_hashagg 参数说明：标识是否依据规则约束使用基于面向列的hash表设计的Hash Agg算子。 参数类型：USERSET 取值范围：布尔型 on表示在满足约束条件时使用基于面向列的hash表设计的Hash Agg算子。 off表示不使用面向列的hash表设计的Hash Agg算子。 在开启enable_sonic_hashagg，且查询达到约束条件使用基于面向列的hash表设计的Hash Agg算子时，查询对应的Hash Agg算子内存使用通常可获得精简。但对于代码生成技术可获得显著性能提升的场景(enable_codegen打开后获得较大性能提升)，对应的算子查询性能可能会出现劣化。 开启enable_sonic_hashagg，且查询达到约束条件使用基于面向列的hash表设计的Hash Agg算子时，在Explain Analyze/Performance的执行计划和执行信息中，算子显示为“Sonic Hash Aggregation”，而未达到该约束条件时，算子名称将显示为“Hash Aggregation”。 默认值：on

enable_sonic_hashjoin 参数说明：标识是否依据规则约束使用基于面向列的hash表设计的Hash Join算子。 参数类型：USERSET 取值范围：布尔型 on表示在满足约束条件时使用基于面向列的hash表设计的Hash Join算子。 off表示不使用面向列的hash表设计的Hash Join算子。 当前开关仅适用于Inner Join的场景。 在开启enable_sonic_hashjoin，查询对应的Hash Inner算子内存使用通常可获得精简。但对于代码生成技术可获得显著性能提升的场景，对应的算子查询性能可能会出现劣化。 开启enable_sonic_hashjoin，且查询达到约束条件使用基于面向列的hash表设计的Hash Join算子时，在Explain Analyze/Performance的执行计划和执行信息中，算子显示为“Sonic Hash Join”，而未达到该约束条件时，算子名称将显示为“Hash Join”。 默认值：on

join_collapse_limit 参数说明：根据得出的列表项数来判断优化器是否执行把除FULL JOINS之外的JOIN构造重写到FROM列表中。 参数类型：USERSET 取值范围：整型，1～INT_MAX。 设置为1会避免任何JOIN重排。这样就使得查询中指定的连接顺序就是实际的连接顺序。查询优化器并不是总能选取最优的连接顺序，高级用户可以选择暂时把这个变量设置为1，然后指定它们需要的连接顺序。 比默认值小的数值减少规划时间但也降低了执行计划的质量。 默认值：8

enable_bloom_filter 参数说明：标识是否允许使用BloomFilter优化。 参数类型：USERSET 取值范围：布尔型 on表示允许使用BloomFilter优化。 off表示不允许使用BloomFilter优化。 默认值：on 适用场景：外表侧同线程包含有HDFS内外表或列存表的HASH JOIN会触发Bloom Filter。 使用限制： JOIN类型仅限于INNER JOIN、SEMI JOIN、RIGHT JOIN、RIGHT SEMI JOIN、RIGHT ANTI JOIN、RIGHT ANTI FULL JOIN。 JOIN内表侧的数据不能超过5万行。 JOIN内表侧关联条件：对于HDFS内外表不能为表达式；对于列存表可以为表达式，但仅限于非JOIN层计算的表达式。 JOIN外表侧关联条件必须为简单列关联。 JOIN内表侧与外表侧关联条件均为简单列关联时，计划层估算必须可以去除1/3以上的数据（仅针对HDFS内外表）。 JOIN不能包含null值关联。 JOIN层未出现下盘。 数据类型： HDFS内外表字段类型支持SMALLINT、INTEGER、BIGINT、REAL/FLOAT4、DOUBLE PRECISION/FLOAT8、CHAR(n)/CHARACTER(n)/NCHAR(n)、VARCHAR(n)/CHARACTER VARYING(n)、CLOB、TEXT。 列存表字段类型支持SMALLINT、INTEGER、BIGINT、OID、"char"、CHAR(n)/CHARACTER(n)/NCHAR(n)、VARCHAR(n)/CHARACTER VARYING(n)、NVARCHAR2(n)、CLOB、TEXT、DATE、TIME、TIMESTAMP、TIMESTAMPTZ，其中字符类型其排序规则必须指定为"C"。

autoanalyze 参数说明：标识是否允许在生成计划的时候，对于“统计信息完全缺失”或“修改量达到analyze阈值”的表进行统计信息自动收集，当前不支持对外表触发autoanalyze，不支持对带有ON COMMIT [DELETE ROWS|DROP]选项的临时表触发autoanalyze，如需收集，需用户手动执行analyze操作。如果在auto analyze某个表的过程中数据库发生异常，当数据库正常运行之后再执行语句有可能仍提示需要收集此表的统计信息。此时需要用户对该表手动执行一次analyze操作，以同步统计信息数据。 表的修改量达到analyze阈值是指：表的修改量超过autovacuum_analyze_threshold + autovacuum_analyze_scale_factor * reltuples，其中reltuples是pg_class中记录的表的估算行数。 参数类型：SUSET 取值范围：布尔型 on表示允许自动进行统计信息收集。 off表示不允许自动进行统计信息收集。 默认值：on

constraint_exclusion 参数说明：控制查询优化器使用表约束查询的优化。 参数类型：USERSET 取值范围：枚举类型 on表示检查所有表的约束。 off表示不检查约束。 partition表示只检查继承的子表和UNION ALL子查询。 当该参数设置为on，优化器用查询条件和表的CHECK约束比较，并且在查询条件和约束冲突的时候忽略对表的扫描。 默认值：partition 目前， constraint_exclusion缺省被打开，通常用来实现表分区。为所有的表打开它时，对于简单的查询强加了额外的规划，并且对简单查询没有什么好处。如果不用分区表，可以关掉它。

enable_extrapolation_stats 参数说明：标识对于日期类型是否允许基于历史统计信息使用推理估算的逻辑。使用该逻辑对于未及时收集统计信息的表可以增大估算准确的可能性，但也存在错误推理导致估算过大的可能性，需要对于日期类型数据定期插入的场景开启此开关。 参数类型：USERSET 取值范围：布尔型 on表示允许基于历史统计信息使用推理估算的逻辑。 off表示不允许基于历史统计信息使用推理估算的逻辑。 默认值：off

plan_mode_seed 参数说明：该参数为调测参数，目前仅支持OPTIMIZE_PLAN和RANDOM_PLAN两种。其中：OPTIMIZE_PLAN表示通过动态规划算法进行代价估算的最优plan，参数值设置为0；RANDOM_PLAN表示随机生成的plan；如果设置为-1，表示用户不指定随机数的种子标识符seed值，由优化器随机生成[1，2147483647]范围整型值的随机数，并根据随机数生成随机的执行计划；如果用户指定guc参数值为[1，2147483647]范围的整型值，表示指定的生成随机数的种子标识符seed，优化器需要根据seed值生成随机的执行计划。 参数类型：USERSET 取值范围：整型，-1~ 2147483647 默认值：0 当该参数设置为随机执行计划模式时，优化器会生成不同的随机执行计划，该执行计划可能不是最优计划。因此在随机计划模式下，会对查询性能产生影响，所以建议在升级、扩容、缩容等正常业务操作或运维过程中将该参数保持为默认值0。 当该参数不为0时，查询指定的plan hint不会生效。

debug_group_dop 参数说明：当query_dop取值为0时，针对生成的执行计划划分的以Stream算子为顶点的group，均分配统一的dop并行度。此参数用于人为指定特定group的dop进行性能调优，格式为G1,D1,G2,D2,...，其中：G1,G2为group的ID，可以从日志中获得，D1,D2为指定的dop值，可以为任意正整数。 参数类型：USERSET 取值范围：字符型 默认值：空 该参数仅供内部调优使用，不允许用户进行设置，建议保持默认值。

default_statistics_target 参数说明：为没有用ALTER TABLE SET STATISTICS设置字段目标的表设置缺省统计目标。此参数设置为正数是代表统计信息的样本数量，为负数时，代表使用百分比的形式设置统计目标，负数转换为对应的百分比，即-5代表5%。采样时，会将default_statistics_target * 300作为随机抽样的大小，例如默认值为100时，会随机读取30000个页面再从中随机取30000条数据来完成随机抽样。 参数类型：USERSET 取值范围：浮点型，-100～10000。 比默认值大的正数数值增加了ANALYZE所需的时间，但是可能会改善优化器的估计质量。 调整此参数可能存在性能劣化的风险，如果某个查询劣化，可以考虑： 恢复默认的统计信息。 使用plan hint来调整到之前的查询计划。 当此guc参数设置为负数时，如果计算的采样样本数大于等于总数据量的2%，且用户表的数据量小于1600000时，ANALYZE所需时间相比guc参数为默认值的时间会有所增加。 当此guc参数设置为负数时，autoanalyze不支持百分比采样，采样过程使用参数默认值。 当此guc参数设置为正数时，用户执行analyze需要被授予ANALYZE权限。 当此guc参数设置为负数时，即百分比采样时，用户执行analyze需要同时被授予ANALYZE和SELECT权限。 默认值：100

如何使用\copy导入导出？ 由于云上GaussDB(DWS)是全托管服务，用户无法登录后台，无法使用copy进行导入导出文件，所以云上将copy语法禁掉。云上推荐将数据文件放到obs上，使用obs外表进行入库，如果需要使用copy导入导出数据，可以参考如下方法： 将数据文件放到客户端的机器上。 使用gsql连接集群。 执行如下命令导入数据，输入数据文件在客户端的目录信息和文件名，with中指定导入选项，跟正常copy一样，但是需要在copy前添加"\"标识，入库成功后不会有消息提示。 \copy tb_name from '/directory_name/file_name' with(...); 执行如下命令，使用默认参数直接导出数据到本地文件。 \copy table_name to '/directory_name/file_name'; 使用copy_option参数导出为CSV文件。 \copy table_name to '/directory_name/file_name' CSV; 使用with指定option参数，导出为CSV文件，分隔符为'|'。 \copy table_name to '/directory_name/file_name' with(format 'csv',delimiter '|') ; 父主题： 数据导入导出

如何调整 通过select version();语句查询当前数据库版本号，版本号不同，调整的方式不同： 8.0.x及以前版本，通过重建表时指定分布列来调整： 通过Data Studio或者Linux下使用gsql访问数据库。 创建新表。 以下步骤语句中，table1为原表名，table1_new为新表名，column1和column2为分布列名称。 1 2 3 4 CREATE TABLE IF NOT EXISTS table1_new ( LIKE table1 INCLUDING ALL EXCLUDING DISTRIBUTION) DISTRIBUTE BY HASH (column1, column2); 迁移数据到新表。 1 2 3 4 START TRANSACTION; LOCK TABLE table1 IN ACCESS EXCLUSIVE MODE; INSERT INTO table1_new SELECT * FROM table1; COMMIT; 查看表数据是否迁移成功，删除原表。 1 2 SELECT COUNT(*) FROM table1_new; DROP TABLE table1; 替换原表。 1 ALTER TABLE table1_new RENAME TO table1; 8.1.0及以后版本后，通过ALTER TABLE语法进行调整，以下为示例。 查询当前表定义，回显发现该表分布列为c_last_name。 1 SELECT pg_get_tabledef('customer_t1'); 尝试执行更新分布列中的数据提示错误信息。 1 UPDATE customer_t1 SET c_last_name = 'Jimy' WHERE c_customer_sk = 6885; 将该表的分布列修改为不会更新的列，例如c_customer_sk。 1 ALTER TABLE customer_t1 DISTRIBUTE BY hash (c_customer_sk); 重新执行更新旧的分布列的数据。更新成功。 1 UPDATE customer_t1 SET c_last_name = 'Jimy'WHERE c_customer_sk = 6885;

选择合适的分布列 Hash分布表的分布列选取至关重要，需要满足以下基本原则： 列值应比较离散，以便数据能够均匀分布到各个DN。例如，考虑选择表的主键为分布列，如在人员信息表中选择身份证号码为分布列。 在满足第一条原则的情况下尽量不要选取存在常量filter的列。 在满足前两条原则的情况，考虑选择查询中的连接条件为分布列，以便Join任务能够下推到DN中执行，且减少DN之间的通信数据量。 支持多分布列特性，可以更好地满足数据分布的均匀性要求。

LibrA、GaussDB A与GaussDB(DWS)是什么关系？ GaussDB(DWS)是一种在线数据处理数据库，是华为自研的GaussDB A（原名FusionInsight LibrA）产品基于华为云基础架构和平台构建而成的。而GaussDB A为物理机的纯软件销售形态，GaussDB A相关文档可访问以下网址获取： 6.5.1及以前版本：https://support.huawei.com/enterprise/zh/cloud-computing/gaussdb-200-pid-21407429 8.0.0版本：https://support.huawei.com/enterprise/zh/cloud-computing/gaussdb-a-pid-250949677 父主题： 通用问题

原因分析 扩容前，如果您没有执行vacuum清理和回收存储空间，GaussDB(DWS)数据仓库中之前被删除的数据，可能没有释放占用的磁盘空间形成脏数据，导致磁盘浪费。 而在扩容时，系统会做一次重分布，集群扩容时新节点添加完成后，原节点存储的业务数据明显多于新节点，此时系统自动在所有节点重新分布保存数据。在开始做重分布时，系统会自动执行一次vacuum，从而释放了存储空间，因此，扩容后已使用存储容量减少了很多。

自定义函数属性设置不合理 场景：自定义函数get_count()并调用该函数出现结果不一致场景。 1 2 3 4 5 6 7 8 9 10 11 CREATE FUNCTION get_count() returns int SHIPPABLE as $$ declare result int; begin result = (select count(*) from test); --test表是hash表 return result; end; $$ language plpgsql; 调用该函数。 1 2 3 4 5 6 7 8 9 10 11 SELECT get_count(); get_count ----------- 2106 (1 row) SELECT get_count() FROM t_src; get_count ----------- 1032 (1 row) 原因分析： 由于该函数指定了SHIPPABLE的函数属性，因此生成计划时该函数会下推到DN上执行，该函数下推到DN后，由于函数定义中的test表是hash表，因此每个DN上只有该表的一部分数据，所以select count(*) from test; 返回的结果不是test表全量数据的结果，而是每个DN上部分数据的结果，因此导致加上from表后函数返回预期发生变化。 解决方法： 以下两种方法任选其一即可（推荐第一种方法）： 将函数改为不下推：ALTER FUNCTION get_count() not shippable; 将函数中用到的表改为复制表，这样每个DN上都是一份该表的全量数据，即使下推到DN执行，也能保证结果集符合预期。

数据库兼容模式 场景：在数据库中查询空串结果不一致。 database1（TD兼容模式）: 1 2 3 4 5 td=# select '' is null; isnull -------- f (1 row) database2（ORA兼容模式）: 1 2 3 4 5 ora=# select '' is null; isnull -------- t (1 row) 原因分析： 查询空串结果不同是由于不同数据库兼容模式下空串与null语法有差异导致。 目前，GaussDB(DWS)支持三种数据库兼容模式：Oracle、TD和MySql，不同兼容模式下语法和行为存在差异，兼容性差异说明可参考Oracle、Teradata和MySQL语法兼容性差异。 不同兼容模式下的database表现出不同的兼容性行为属于正常现象。可以通过查看select datname, datcompatibility from pg_database;确认数据库兼容性设置是否相同。 解决方法： 这种场景下只能将两个database的兼容性模式设置为一致的才能解决。Database的DBCOMPATIBILITY属性不支持ALTER，只能通过新建数据库的方法，在创建数据库时指定相同的DBCOMPATIBILITY属性解决。

数据库兼容性行为配置项behavior_compat_options设置不同 场景：add_months函数计算结果不一致。 database1: 1 2 3 4 5 SELECT add_months('2018-02-28',3) from dual; add_months --------------------- 2018-05-28 00:00:00 (1 row) database2: 1 2 3 4 5 SELECT add_months('2018-02-28',3) from dual; add_months --------------------- 2018-05-31 00:00:00 (1 row) 原因分析： 数据库兼容性配置项behavior_compat_options不同会导致部分行为不同，该参数选项可参考behavior_compat_options中的相关选项描述。 此场景中behavior_compat_options配置项中的end_month_calculate参数控制add_months函数计算逻辑配置项。设置end_month_calculate配置项时，如果param1的日期（Day字段）为月末，并且param1的日期（Day字段）比result月份的月末日期比小，计算结果中的日期字段（Day字段）和result的月末日期保持一致。 解决方法： 需要将数据库中参数behavior_compat_options的兼容性配置项设置为一致。该参数类型为USERSET类型，可session级别设置或集群级修改。

使用UNLOGGED表 场景： 使用unlogged表后，在集群重启后，关联查询结果集异常，查看unlogged表缺少部分数据。 原因分析： 如果设置max_query_retry_times为0，且在建表时指定UNLOGGED关键字，则创建的表为非日志表。在非日志表中写入的数据不会被写入到预写日志中，这样就会比普通表快很多。但是非日志表在冲突、执行操作系统重启、强制重启、切断电源操作或异常关机后会被自动截断，会造成数据丢失的风险。非日志表中的内容也不会被复制到备服务器中。在非日志表中创建的索引也不会被自动记录。因此当集群发生异常重启（进程重启、节点故障、集群重启）时，会导致部分内存中的数据未及时落盘，造成部分数据丢失，从而导致结果集异常。 解决方法： unlogged表在集群异常情况下的安全性无法保证，一般不能作为业务表使用，更多的场景是作为临时表使用。当出现集群故障后，为了保证数据正常，需要重建unlogged表或将数据备份后重新导入数据库。

子查询limit 场景：子查询中使用limit，两次查询结果不一致。 1 2 3 4 5 6 7 8 9 10 11 SELECT * FROM (select a from test limit 1 ) order by 1; a --- 5 (1 row) SELECT * FROM (select a from test limit 1 ) order by 1; a --- 1 (1 row) 原因分析： 子查询中的limit会导致获取随机结果，从而最终查询结果为随机提取。 解决方法： 要保证最终查询结果的稳定，需避免在子查询中使用limit。

子视图/子查询中使用排序 场景： 创建表test和视图v后，子查询中使用排序查询表test，出现查询结果不一致。 1 2 3 4 5 6 CREATE TABLE test(a serial ,b int); INSERT INTO test(b) VALUES(1); INSERT INTO test(b) SELECT b FROM test; … INSERT INTO test(b) SELECT b FROM test; CREATE VIEW v as SELECT * FROM test ORDER BY a; 问题SQL： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 SELECT * FROM v limit 1; a | b ---+--- 3 | 1 (1 row) SELECT * FROM (select * from test order by a) limit 10; a | b ----+--- 14 | 1 (1 row) SELECT * FROM test order by a limit 10; a | b ---+--- 1 | 1 (1 row) 原因分析： 对于子视图和子查询中order by是无效的。 解决方法： 不建议在子视图和子查询中使用order by，若要保证结果有序，需在最外层查询中使用order by。

使用string_agg 场景：使用string_agg查询表employee，出现查询结果不一致。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 SELECT * FROM employee; empno | ename | job | mgr | hiredate | sal | comm | deptno -------+--------+---------+------+---------------------+-------+------+-------- 7654 | MARTIN | SALEMAN | 7698 | 2022-11-08 00:00:00 | 12000 | 1400 | 30 7566 | JONES | MANAGER | 7839 | 2022-11-08 00:00:00 | 32000 | 0 | 20 7499 | ALLEN | SALEMAN | 7698 | 2022-11-08 00:00:00 | 16000 | 300 | 30 (3 rows) SELECT count(*) FROM (select deptno, string_agg(ename, ',') from employee group by deptno) t1, (select deptno, string_agg(ename, ',') from employee group by deptno) t2 where t1.string_agg = t2.string_agg; count ------- 2 (1 row) SELECT count(*) FROM (select deptno, string_agg(ename, ',') from employee group by deptno) t1, (select deptno, string_agg(ename, ',') from employee group by deptno) t2 where t1.string_agg = t2.string_agg; count ------- 1 (1 row) 原因分析： String_agg函数的作用是将组内的数据合并成一行，但是如果某用户的用法是string_agg(ename, ',') ，结果集就是不稳定的，因为没有指定组合的顺序。例如，上述语句中，对于select deptno, string_agg(ename, ',') from employee group by deptno; 输出结果既可以是： 1 30 | ALLEN,MARTIN 也可能是： 1 30 |MARTIN,ALLEN 两个结果都是合理的，因此上述关联场景下，有可能出现t1这个subquery中的结果和t2这个subquery中的结果对于deptno=30时的输出结果不一致。 解决方法： String_agg中增加order by排序，保证按顺序拼接。 1 SELECT count(*) FROM (select deptno, string_agg(ename, ',' order by ename desc) from employee group by deptno) t1 ,(select deptno, string_agg(ename, ',' order by ename desc) from employee group by deptno) t2 where t1.string_agg = t2.string_agg;

窗口函数中使用排序后取部分结果 场景： 窗口函数row_number()中使用排序后查询表t3的c列，两次查询结果不同。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 SELECT * FROM t3 order by 1,2,3; a | b | c ---+---+--- 1 | 2 | 1 1 | 2 | 2 1 | 2 | 3 (3 rows) SELECT c,rn FROM (select c,row_number() over(order by a,b) as rn from t3) where rn = 1; c | rn ---+---- 1 | 1 (1 row) SELECT c,rn FROM (select c,row_number() over(order by a,b) as rn from t3) where rn = 1; c | rn ---+---- 3 | 1 (1 row) 原因分析： 如上所示，执行同一条语句：select c,rn from (select c,row_number() over(order by a,b) as rn from t3) where rn = 1; 两次查询结果不同，因为在窗口函数的排序列a、b上存在重复值1、2且重复值在c列上的值不同，就会导致每次按照a，b列排序结果取第一条时，所取的数据是随机的，造成结果集不一致。 解决方法： 该场景需要将取值列c列也加到排序中，使排序结果获取的第一条数据固定。 1 2 3 4 5 SELECT c,rn FROM (select c,row_number() over(order by a,b,c) as rn from t3) where rn = 1; c | rn ---+---- 1 | 1 (1 row)