序列Sequence是用来产生唯一整数的数据库对象。序列的值是按照一定规则自增的整数。因为自增所以不重复，因此说Sequence具有唯一标识性。因此，在数据库中Sequence常常被作为主键使用。通过序列使某字段成为唯一标识符的方法有两种：是声明字段的类型为序列整型，由数据库在后台自动创建一个对应的Sequence。使用CREATE SEQUENCE自定义一个新的Sequence，然后将nextval(‘sequence_name’)函数读取的序列值，指定为某一字段的默认值，这样该字段就可以作为唯一标识符。方法一： 声明字段类型为序列整型来定义标识符字段。方法二： 创建序列，并通过nextval(‘sequence_name’)函数指定为某一字段的默认值。这种方式更灵活，可以为序列定义cache，一次预申请多个序列值，减少与GTM的交互次数，来提高性能。除了为序列指定了cache，方法二所实现的功能基本与方法一类似。但是一旦定义cache，序列将会产生空洞(序列值为不连贯的数值，如：1.4.5)，并且不能保序。另外为某序列指定从属列后，该列删除，对应的sequence也会被删除。 虽然数据库并不限制序列只能为一列产生默认值，但最好不要多列共用同一个序列。

优点是：JSON则天然支持Schema Evoluation，上游业务的变更，只需要在JSON列数据中进行增删相应的字段，无需对数仓中的表做任何DDL就能完成，也能对中间的ETL作业做到透明，最大程度地保留了半结构化数据的易用性和灵活性，能大大降低维护和管理表结构的成本。缺点是：应用端查询时需要选择合适的处理函数和方法，才能解析到需要的数据，开发较为复杂，如果JSON较复杂，同时查询性能会有退化，因为每次JSON列的数据参与计算的时候，都需要对JSON数据完整的解析一遍，比如需要抽取出整个JSON中某个字段，那么查询引擎执行的时候就要读出每一行JSON，解析一遍，取出需要的字段再返回。这中间会涉及大量的IO和计算，而需要的可能只是JSON数据成百上千字段当中的一个字段，这中间的大量IO和计算都是浪费的。另外，当前云原生分支上JSON的向量化支持仍然是沿用的通用的向量化框架，没有定制化的向量化函数。通用的向量化函数框架本质上来说仍然为行存的调用，并不是完全意义上的向量化。如上所述，后续想要提升JSON/JSONB的查询性能，首先必须提升JSON的存储方式，即在解析前端将JSON拍平成宽表，真正意义上发挥JSON半结构化数据的优势。这种做法的优点是：写入DWS时，因为是普通列写入，所以写入性能会更好，同时在查询侧，不需要对JSON数据进行解析，查询性能也会更好。缺点是：每当上游的数据格式有变更时，比如变更数据类型、增删字段、执行DDL进行加列或者删列，中间的实时数据ETL作业也需要进行适配改动并重新上线，使用非常不灵活，也会额外增加运维和开发负担。并且当JSON的每一个键值都为一列，若出现异常数据，可能导致列数的急速膨胀，进而影响性能。另外，当前列存JSON的性能当前瓶颈点在于向量化的性能，一方面需要提升通用当前DWS的向量化能力，另一方面也可以考虑对JSON函数做出优化。

比较规则如下：首先比较类型：object-jsonb > array-jsonb > bool-jsonb > num-jsonb > str-jsonb > null-jsonb同类型则比较内容：str-json类型：依据text比较的方法，使用数据库默认排序规则进行比较，返回值正数代表大于，负数代表小于，0表示相等。num-json类型：数值比较bool-json类型：true > falsearray-jsonb类型：长度长的 > 长度短的，长度相等则依次比较每个元素。object-jsonb类型：长度长的 > 长度短的，长度相等则依次比较每个键值对，先比较键，再比较值。目前，DWS的JSON/JSONB的功能基本完善。主要体现在函数、操作符、索引功能的支持。但目前来说，JSON列存仍然采用的是直接存储JSON数据，即将原始的JSON数据存成单独的一列，以完整的JSON值作为最小的粒度在磁盘上

jsonb_object_field(jsonb, text)描述：输入的JSON类型为json-object，返回指定键对应的值（可能为json-object或json-array）对应操作符：->返回类型：JSONBjsonb_array_element(array-jsonb, integer)描述：输入的JSON类型为json-array，返回数组中指定下标的元素（为任意合法的JSON）对应操作符：->返回类型：JSONBjsonb_extract_path((jsonb, VARIADIC text[])描述：输入为json-object或json-array，返回$2所指路径的值。$2中可以为json-object对应的键值(字符串类型)，也可以为json-array对应的下标(整数类型)对应操作符：#>注意：GaussDB(DWS)对象标识符支持以符号"#“结尾，为避免a#>b解析过程出现歧义，因此操作符”#>"前后需要增加空格，否则解析报错。返回类型：JSONB

标量(scalar)：输入为数字、布尔类型时，使用单引号 ’ '声明，输入为字符串时必须加 " "声明数组(array)：使用中括号[]包裹，满足数组书写条件。数组内元素类型可以是任意合法的JSON，且不要求类型一致。对象(object)：使用大括号{}包裹，键必须是满足JSON字符串规则的字符串，值可以是任意合法的JSON。嵌套数组和对象：数组array中可以是任意合法的JSON元素，对象object则严格遵循了key:value的格式，两者结合可以方便地有序查找JSON值。

JSON（JavaScript Object Notation）是一种轻量级的数据交换格式，常用于将数据从服务器发送到Web应用程序。它采用人类易读和机器易解析的文本格式，基于键值对的集合，用于表示结构。JSON数据类型可以用来存储JSON（JavaScript Object Notation）数据。可以是单独的一个标量，也可以是一个数组，也可以是一个键值对象，其中数组和对象可以统称容器(container)：标量(scalar)：单一的数字、bool、string、null都可以叫做标量。数组(array)：[]结构，里面存放的元素可以是任意类型的JSON，并且不要求数组内所有元素都是同一类型。对象(object)：{}结构，存储key:value的键值对，其键只能是用“”包裹起来的字符串，值可以是任意类型的JSON，对于重复的键，按最后一个键值对为准。存储方式JSON是输入字符串的完整拷贝，使用时再去解析，所以它会保留输入的空格，重复键以及顺序等；JSONB解析后存储，删除语义无关的细节和重复的键，对键值也会进行排序，使用时不用再次解析。性能差别JSON由于精确拷贝，因此插入时性能较好，但是其在处理函数时，必须在每个执行上重新解析，因此其查询性能一般；JSONB 数据以分解的二进制格式存储， 这使得它由于添加了转换机制而在输入上稍微慢些。但是其由于插入后即默认有序排列，因此可以更好地支持的额外操作（如bool关系的比较，顶层元素存在的判断）。并且，其在处理函数时， 不需要重新解析，查询性能较好。同时，JSONB支持创建btree、gist和gin索引。

max_active_statements设置全局的最大并发数量。此参数只应用到CN，且针对一个CN上的执行作业。需根据系统资源（如CPU资源、IO资源和内存资源）情况，调整此数值大小，使得系统支持最大限度的并发作业，且防止并发执行作业过多，引起系统崩溃。当取值-1或者0时，不限制全局并发数。在点查询的场景下，参数建议设置为100。在分析类查询的场景下，参数的值设置为CPU的核数除以DN个数，一般可以设置5~8个。bulk_write_ring_size数据并行导入使用的环形缓冲区大小。该参数主要影响入库性能，建议导入压力大的场景增加DN上的该参数配置。checkpoint_completion_target指定检查点完成的目标。含义是每个checkpoint需要在checkpoints间隔时间的50%内完成。默认值为0.5，为提高性能可改成0.9。data_replicate_buffer_size发送端与接收端传递数据页时，队列占用内存的大小。此参数会影响主备之间复制的缓冲大小。默认值为128MB，若服务器内存为256G，可适当增大到512MB。wal_receiver_buffer_size备机与从备接收Xlog存放到内存缓冲区的大小。默认值为64MB，若服务器内存为256G，可适当增大到128MB

连接相关的参数有两个：max_connections和max_prepared_transactionsmax_connections允许和数据库连接的最大并发连接数。此参数会影响集群的并发能力。设置建议：CN中此参数建议保持默认值。DN中此参数建议设置为CN的个数乘以CN中此参数的值。增大这个参数可能导致GaussDB(DWS)要求更多的System V共享内存或者信号量，可能超过操作系统缺省配置的最大值。这种情况下，请酌情对数值加以调整。max_prepared_transactions设置可以同时处于"预备"状态的事务的最大数目。增加此参数的值会使GaussDB(DWS)比系统默认设置需要更多的System V共享内存。NOTICE:max_connections取值的设置受max_prepared_transactions的影响，在设置max_connections之前，应确保max_prepared_transactions的值大于或等于max_connections的值，这样可确保每个会话都有一个等待中的预备事务。

影响数据库性能的五大内存参数有：max_process_memory、shared_buffers、cstore_buffers、work_mem和maintenance_work_mem。max_process_memorymax_process_memory是逻辑内存管理参数，主要功能是控制单个CN/DN上可用内存的最大峰值。计算公式：max_process_memory=物理内存*0.665/(1+主DN个数)。shared_buffers设置DWS使用的共享内存大小。增加此参数的值会使DWS比系统默认设置需要更多的System V共享内存。建议设置shared_buffers值为内存的40%以内。主要用于行存表scan。计算公式：shared_buffers=(单服务器内存/单服务器DN个数)0.40.25cstore_buffers设置列存和OBS、HDFS外表列存格式（orc、parquet、carbondata）所使用的共享缓冲区的大小。计算公式可参考shared_buffers。work_mem设置内部排序操作和Hash表在开始写入临时磁盘文件之前使用的内存大小。ORDER BY，DISTINCT和merge joins都要用到排序操作。Hash表在散列连接、散列为基础的聚集、散列为基础的IN子查询处理中都要用到。对于复杂的查询，可能会同时并发运行好几个排序或者散列操作，每个都可以使用此参数所声明的内存量，不足时会使用临时文件。同样，好几个正在运行的会话可能会同时进行排序操作。因此使用的总内存可能是work_mem的好几倍。计算公式：对于串行无并发的复杂查询场景，平均每个查询有5-10关联操作，建议work_mem=50%内存/10。对于串行无并发的简单查询场景，平均每个查询有2-5个关联操作，建议work_mem=50%内存/5。对于并发场景，建议work_mem=串行下的work_mem/物理并发数。maintenance_work_memmaintenance_work_mem用来设置维护性操作（比如VACUUM、CREATE INDEX、ALTER TABLE ADD FOREIGN KEY等）中可使用的最大的内存。当自动清理进程运行时，autovacuum_max_workers倍数的内存将会被分配，所以此时设置maintenance_work_mem的值应该不小于work_mem。

GaussDB(DWS)支持并行计算技术，当系统的CPU、内存、I/O和网络带宽等资源充足时，可以充分利用富余硬件资源，提升语句的执行速度。在GaussDB(DWS)中，通过query_dop参数，来控制语句的并行度，取值如下：query_dop=1，串行执行query_dop=[2…N]，指定并行执行并行度query_dop=0，自适应调优，根据系统资源和语句复杂度情况自适应选择并行度query_dop参数设置的一些原则：对于短查询为主的TP类业务中，如果不能通过CN轻量化或下发语句进行业务的调优，则生成SMP计划的时间较长，建议设置query_dop=1。对于AP类复杂语句的场景，建议设置query_dop=0。计划并行执行之后必定会引起资源消耗的增加，当资源成为瓶颈的情况下，SMP无法提升性能，反而可能导致性能的劣化。出现资源瓶颈的情况下，建议关闭SMP，即设置query_dop=1。设置query_dop=0可以实现自适应调优，在部分场景下语句执行的并行度没有达到最优，这种情况可以考虑通过query_dop参数设置并行度。

HDC2025大会即将举行，大家会去现场参加么，希望看到哪些内容？

请问dws当中，分区表数据入库时，是先分区呢还是先分布？分区是以怎样的形式存在各个DN当中的？分区键和分布列如何选择，两者需要相同吗?按照我的理解，分布不是相当于已经分了一次区了吗？分区的操作对象难道是单个dn的表数据吗？

通信协议不匹配问题cid:link_2语句出错怎么排查cid:link_3认识数据库视图对象cid:link_4数据库视图提供了额外的安全层cid:link_5视图对表结构的依赖cid:link_6GaussDB(DWS)常用系统视图cid:link_7视图解耦cid:link_8底层对象改变，视图置为无效cid:link_9无效视图使用，视图刷新有效cid:link_10如何递归查询视图依赖cid:link_11了解HiveMetaStorecid:link_0external schema与schema的区别cid:link_12创建EXTERNAL SCHEMAcid:link_13GUC参数调优cid:link_1enable_sort参数https://bbs.huaweicloud.com/forum/thread-0259181318729277041-1-1.html

GaussDB(DWS)中实现分组聚集操作有两种方法：HashAgg：使用Hash表对数据进行去重，并同时进行聚集操作，适用于聚集后行数缩减较多的场景。Sort + GroupAgg：首先对数据进行排序，然后遍历排序后的数据，完成去重和聚集操作，适用于聚集后行数缩减较少的场景。如果使用Sort + GroupAgg的方式，在Sort排序算子里执行时间比较长，因为需要对大量数据进行排序操作。GaussDB(DWS)中通过count distinct来统计多个列的数据时，通常会使用HashAgg来实现每一个列的统计聚集操作，然后将结果通过Join方式关联起来得到最终结果。从查询计划来看，通过count distinct统计了lineitem表中的6列数据，是通过6个HashAgg操作来实现的，该SQL执行时消耗的资源相对较高。如果关闭enable_hashagg参数，优化器会选择Sort + GroupAgg的方式，该SQL执行时消耗的资源相对较少。在应用开发时，可以根据SQL并发和资源使用情况，通过设置enable_hashagg参数来选择合适的执行计划。

系统级调优中数据库全局的GUC参数对整体性能的提升至关重要，而在语句级调优中GUC参数可以调整估算模型，选择查询计划中算子的类型，或者选择不同的执行计划。因此在SQL调优过程中合理的设置GUC参数十分重要。查询计划的生成是基于一定的模型和统计信息进行代码估算，在某些场景由于统计信息不准确或者代价估算有偏差时，就需要通过GUC参数设置的的方式选择更优的查询计划。在GaussDB(DWS)中，和SQL执行性能相关的GUC参数主要有以下几个：best_agg_plan: 进行聚集计算模型的设置enable_sort: 控制优化器是否使用的排序，主要用于让优化器选择使用HashAgg来实现聚集操作enable_hashagg：控制优化器是否使用HashAgg来实现聚集操作enable_force_vector_engine：开启参数后强制生成向量化的执行计划query_dop：用户自定义的查询并行度GaussDB(DWS)是分布式的数据库集群，数据计算尽量在各个DN上并行计算，可以得到最优的性能，在Stream框架下Agg操作可以分为两个场景。Agg下层算子输出结果集的分布列是Group By列的子集这种场景，直接对下层结果集进行汇聚的结果就是正确的汇聚结果，生成算子直接使用即可。例如以下语句，lineitem的分布列是l_orderkey，它是Group By的列。Agg下层算子输出结果集的分布列不是Group By列的子集。对于这种场景Stream下的聚集（Agg）操作，优化器可以生成以下三种形态的查询计划：hashagg+gather(redistribute)+hashaggredistribute+hashagg(+gather)hashagg+redistribute+hashagg(+gather)