最近在写gaussdb的巡检指标，补充fusioncare和tpops未覆盖的巡检项。遇到如下几个问题，请专家帮忙解答一下，感谢：gaussdb除了调用API，是否能够通过sql来查询数据库的备份记录和备份配置？如何查看最近7天的统计信息收集记录（自动收集&手动收集）？如何查看统计信息过期的对象（如表/索引）？gaussdb整个体系中，有哪些数据同步工作（集中式主备DN间？DRS？容灾集群间？），它们各自的同步原理是什么？

2025华为开发者大赛总决赛暨开发者年度盛典大家有何收获

通用连接规范cid:link_6连接池规范cid:link_7表设计最佳实践cid:link_0分布方式选择策略cid:link_1分区选择策略cid:link_8索引设计最佳实践cid:link_9索引基本原则cid:link_2SQL 查询最佳实践cid:link_10存储过程最佳实践cid:link_3TOPSQL配置cid:link_4业务排队应急预案cid:link_5锁等待应急预案cid:link_11Stream 多应急预案cid:link_12Pipeline 并行cid:link_13持续学习的目标与特性https://bbs.huaweicloud.com/forum/thread-0282202484206444164-1-1.html

持续学习的目标是在模型持续输入学习新数据的同时避免旧知识的遗忘，以下是其性质与定义。 可以看出LLM实际上已经满足了大部分持续学习的性质，百亿千亿级别的大模型经过充足的预训练后，具备大量世界知识以及涌现能力，基于此进行终身学习成为可能。 常见的LLM终身学习方法如Rehearsal（排练）、 Regularization（正则）、Architectural（结构改造）等方式在LLM的参数量和训练模式下其实都不太适用。而LLM本身为了增大参数量和减少推理成本的混合专家方法(Mixture of Experts, MoE) 似乎成了LLM终身学习的新途径。MoE即混合专家模型，英文叫Mixture of Experts, 发展至今已有30多年历史。MoE是一种模型设计策略，它通过将多个模型直接结合在一起，以获得更好的预测性能。在大模型中，MoE方案可以有效的提高模型的容量和效率。 一般来说，大模型的MoE有一个门控机制和一套门控输出机制来合并和平衡专家的选择；有一套专家模型选择机制，会根据门控机制的输出选择一部分专家模型进行预测。这样可以较少计算量，并使模型能够针对不同的输入选择最合适的专家模型。

受server间通信带宽低的影响，传统数据并行叠加模型并行的这种混合并行模式的性能表现欠佳，需要引入流水线并行。流水线并行能够将模型在空间上按stage进行切分，每个stage只需执行网络的一部分，大大节省了内存开销，同时缩小了通信域，缩短了通信时间。流水线（Pipeline）并行是将神经网络中的算子切分成多个阶段（Stage），再把阶段映射到不同的设备上，使得不同设备去计算神经网络的不同部分。 在计算某些反向算子时，需要用到一些正向算子的计算结果，导致这些正向算子的计算结果需要驻留在内存中，直到依赖它们的反向算子计算完，这些正向算子的计算结果占用的内存才会被复用。这一现象推高了训练的内存峰值，在大规模网络模型中尤为显著。如：Dropout、Activations。在进行数据并行训练时，模型的参数更新部分在各卡间存在冗余计算，优化器并行通过将优化器的计算量分散到数据并行维度的卡上，在大规模网络上（比如Bert、GPT）可以有效减少内存消耗并提升网络性能。 传统的数据并行模式将模型参数在每台设备上都有保有副本，把训练数据切分，在每次迭代后利用通信算子同步梯度信息，最后通过优化器计算对参数进行更新。数据并行虽然能够有效提升训练吞吐量，但并没有最大限度地利用机器资源。其中优化器会引入冗余内存和计算，消除这些冗余是需关注的优化点。 

排查是否存在执行时间很久的SQL语句，并识别每个用户账号的并发数。 1) 排查是否存在执行时间很久的语句，可以杀掉执行时间很久的语句观察整体并发是否有下降； select * from pgxc_stat_activity where state != 'idle' and application_name not like'%cn_%' order by query_start limit 30; 2) 识别每个用户账号的并发数，可以通过锁定低优先级账号或锁定并发数异常的账号进行应急。 select count(*), usename from pgxc_stat_activity where state != 'idle' andapplication_name not like '%cn_%' group by 2;1) 当出现stream多的语句时，可观察探针性能，若探针关联查询性能劣化，则杀掉stream多的语句进行应急，并反馈给业务进行优化；若探针性能无劣化，则持续观察； 2) stream多的语句优化建议： 减少join数量； 减少union all数量； 减少子查询数量； 拆分语句。 

1) 查看详细锁等待信息； select * from pgxc_lock_conflicts order by locktype, relname, partname,transactionid::text, nodename; 2) 根据locktype、relname、partname、transactionid信息识别每一组持锁语句和等锁语句； locktype为relation的，relname相同的记录为同一组； locktype为partition的，relname与partname都相同的记录为同一组； locktype为transactionid 的，transactionid相同的记录为同一组，表示行级锁冲突。 3) 对每一组锁冲突语句依次分析，granted为t表示持锁正在跑的语句，granted为f表示正在申请锁被阻塞的语句； 4) 对于locktype为relatione和partition的，识别等锁语句和持锁语句后，若多个等锁语句被一个持锁语句阻塞，可通过杀掉持锁语句进行应急，并分析该语句长时间持锁跑不完的原因； 对于locktype为transactionid的，表示行级锁冲突，一般为并发更新(update/delete)场景，容易出现在列存场景下，此场景一般为多个update或delete频繁变化持锁和等锁状态，杀掉单个语句无法解决此问题，需要业务侧调整逻辑，避免列存并发更新。 5) 分布式死锁：对于locktype为relatione和partition的，如果出现在某个DN上语句A持锁，语句B等锁，另一个DN上语句B持锁，语句A等锁，这种现象称为分布式死锁；对于分布式死锁场景，可以通过杀掉其中任意一条语句使得另一条语句优先执行成功，再重新执行被杀掉的语句。 

1) 识别是高并发排队还是内存估算导致的ccn排队； select count(1), usename, enqueue from pgxc_stat_activity where state != 'idle'and application_name not like '%cn_%' and enqueue != 'no waiting queue' andenqueue is not null group by 2,3; 2) 如果排队主要是waiting in global queue，说明主要是高并发导致排队，需要排查是否存在执行时间很久的SQL语句，并识别每个用户账号的并发数； a) 排查是否存在执行时间很久的语句，可以杀掉执行时间很久的语句观察整体并发是否有下降； select * from pgxc_stat_activity where state != 'idle' and application_name not like'%cn_%' order by query_start limit 30; b) 识别每个用户账号的并发数，可以通过锁定低优先级账号或锁定并发数异常的账号进行应急。 select count(*), usename from pgxc_stat_activity where state != 'idle' andapplication_name not like '%cn_%' group by 2; 3) 如果排队主要是wait in ccn，说明是ccn排队，需要排查当前估算内存最大的语句top5，可以杀掉估算内存最大的语句进行应急； select * from pgxc_wlm_session_statistics order by estimate_memory desc limit 20; 4) 杀掉该语句后，可以根据上一步的查询结果确认语句实际占用内存与估算内存是否接近，若实际使用内存不高，估算内存高，可通过对表做analyze尝试规避，或session级设置query_mem参数进行规避；若语句实际使用内存很高，则需要对语句进行优化。

在实际的生产环境中，难免会出现一些突发情况，导致查询语句出现异常中断、阻塞时间长等情况，如果当时没能记录下来，那么事后就要投入更多的人力以及时间成本去对错误进行定位和解决，有时还往往定位不到错误出现的地方。为了解决这种情况，DWS提供了历史TOPSQL和实时TOPSQL功能，用以查看sql语句级别的性能开销。TOPSQL中会记录作业运行时的资源使用情况，包括内存、下盘、CPU时间、执行总时间、排队时间等信息，并且会打印性能告警信息，同时也会记录语句对应的执行计划信息。其中，实时TOPSQL会显示当前正在运行的语句的执行情况，语句执行完成后，这些信息会转储到历史TOPSQL中。使用TOPSQL功能需要在管控面上设置如下参数： enable_resource_track: on（表示开启topsql功能）； enable_resource_record: on（表示开启topsql的转储功能，可以查到历史topsql）； enable_track_record_subsql: on（表示可以记录存储过程中的内部语句）； resource_track_cost: 0（执行代价大于resource_track_cost的作业会被记录，设置为0表示除特殊数据定义语句外（SET、SHOW、ALTER、DROP等），可以记录所有DML/SELECT等语句）； resource_track_duration: 0（执行时间大于resource_track_duration的作业会被记录，设置为0表示除特殊数据定义语句外（SET、SHOW、ALTER、DROP等），可以记录所有DML/SELECT等语句）

存储过程是在大型数据库系统中为了完成特定功能而封装的一组SQL语句集，经编译后存储在数据库中，用户通过指定存储过程的名称并设置参数（如果该存储过程带有参数）来执行它。关于存储过程的使用，议论很多，褒贬不一，这里列出主要的优缺点。缺点 ：开发演进难，应用开发完成后，随着用户需求变化、数据结构变化、数据量变化，存储过程的迭代修改、验证难度会非常大。 优点 ：可重复使用，功能使用存储过程封装可以减少数据库开发人员的开发工作量。 调试困难，相比一般的应用SQL开发，存储过程的开发缺少有效的调试工具。 相对安全性，可以隐藏执行逻辑，只暴露名称和参数。 维护困难，随着SQL行数的增加，维护复杂度呈线性提升。 移植问题，参加过数据库迁移的同学都应该知道，最难莫过于超大存储过程的迁移。 综上存储过程的优缺点，建议如下： 存储过程不建议大规模使用； 针对业务流程相对简单的功能，可以使用存储过程封装，因逻辑简单，可以快速调整演进和验证，即使碰到问题也能快速定位修复； 针对业务流程相对复杂的功能，不建议使用存储过程，因为无论是调试、演进还是维护的难度都会让所谓的优点不值一提。

低效类型 语句不下推（分布式） 语句特征：含不下推函数、语法。 计划特征：含_REMOTE_TABLE_QUERY_关键字。 子查询不提升（内部多次执行） 语句特征：含not exists、notin等。 计划特征：含SubPlan关键字。 优化方法 通过topsql或CN找到不下推因素并整改。 改写SQL消除SubPlan。 资源消耗类（CPU） 语句特征：含多个UNION ALL、聚集操作等。 固定数据使用中间表，减少过程中CPU消耗。 资源消耗类（IO） 计划特征：含多个agg、append等算子。 语句特征：行存大表全表扫描、COUNT等。 计划特征：Seq Scan数据量大，Temp file下盘等。 根据业务场景，使用索引、列存等手段降IO。 资源消耗类（内存） 语句特征：关联、聚集操作多，数据量大。 计划特征：join、agg层数据量大固定数据使用中间表，减少过程中内存消耗。 资源消耗类（网络） 语句特征：表关联条件不包含分布列。 计划特征：Stream层数据量大。 调整表的分布列或者调整关联条件列，减少Stream通信数据量。  语句特征：like操作、or操作等。 等价修改为精确匹配、and操作。

索引可以用来提高数据库查询性能，但是不恰当的使用将导致数据库性能下降。建议仅在匹配如下某条原则时创建索引。 经常作为where子句的过滤条件上的字段； 经常作为连接条件的字段，对于存在多字段连接的查询，建议在这些字段上建立组合索引； 例如， select * from t1 join t2 on t1.a=t2.a and t1.b=t2.b，可以在t1表上的a，b字段上建立组合索引。 经常出现在order by、 group by后的字段； 经常作为查询返回结果的字段，distinct、max后的字段； 创建组合索引时，区分度高（DISTINCT值多）的列放前面。 分析过程： 1) 每5min从上游同步一次数据 -> 高频实时入库场景，推荐使用行存表； 2) 表数据量10亿 -> 数据量较大，评估该表查询模型，是否涉及多表关联的分析型查询； 3) 查询性能要求高，涉及多表关联分析型查询 -> 需要列存提升性能。

索引之利 ：提供主键和唯一性约束，满足业务需要 索引之弊 ：索引页面占用额外空间，导致一定的磁盘膨胀 点查询提速显著，直接定位到需要的数据，减少无效IO 利用等值条件索引查询速度快的优势，结合nestloop提高多表join效率 影响数据增删改的性能，因都涉及索引更新操作 索引需要记录XLOG，更新索引会增加主备同步压力 利用索引天然有序的特质，加速排序、求max等操作性能 当统计信息收集不及时触发优化器误判选到不该选的索引计划，可能导致查询性能反向劣化 利用倒排索引加速全文检索 分区表上每个分区都有各自的索引，分区和索引过多会增加cache memory等公共资源的消耗btree 行存默认索引类型（列存也支持），适用于主键、点查场景 相比psort，无论是点查还是范围查询，性能均更优；略微不足的是磁盘空间的占用及对导入性能的影响比psort稍差。 psort 列存默认索引类型，适用于范围查询场景 性能提升效果比较中庸，在列存支持btree后，建议直接用btree索引 注意：列存表上创建索引不指定类型时默认是psort，所以建议在列存上创建索引时显示指定索引类型为btree。 通用倒排索引，适用于全文检索场景 特定场景使用 通用搜索树索引，适用于位置检索场景 特定场景使用

分区相当于把逻辑上的一张表根据分区键划分成几张小表进行分别存储，建议大表都考虑做分区，其好处主要有： 1) 改善查询性能：对分区对象的查询可以仅搜索自己关心的分区，提高检索效率； 2) 增强可用性：如果分区表的某个分区出现故障，表在其他分区的数据仍然可用； 3) 方便维护：定期删除数据的场景，可只针对特定分区做TRUNCATE PARTITION和DROP PARTITION，效率高且不产生脏数据，维护成本低。 （RangePartitioning） 根据分区键值的范围，将数据存储到不同的分区中，分区键范围连续但不重叠。 1、日期或者时间类的字段作为分区键 2、查询中大多包含分区键作为过滤条件 3、定期按照分区键清理数据 列表分区（ListPartitioning） 根据分区键值的列表进行分区，各分区的列表值不重复 1、特定数量的枚举值作为分区键值 2、查询中大多包含分区键作为过滤条件 

分布方式主要决定了数据的存储分布情况，同时也直接影响后续关联查询的计算效率。Hash：表数据按照分布列生成的hash值与 DN实例的映射关系，将数据分布到各DN实例。 优点：每个DN仅包含部分数据，占用整体空间小。 大表、事实表。 缺点：数据分布的均匀程度强依赖分布列的选择；JOIN关联条件不包含各自分布列的场景存在节点间数据通信的消耗。 RoundRobin 表数据按照轮询的方式依次分布到各DN实例。 优点：每个DN仅包含部分数据，占用整体空间小；数据轮询均匀分布，不依赖分布列，不存在数据存储倾斜问题。 缺点：无法通过分布列条件消除和减少节点间通信，此类场景性能不如Hash分布方式。 Replication 表中的全量数据在集群的每一个DN实例上保留一份。 优点：每个DN上都有此表的全量数据，JOIN操作中可以完全避免节点间数据通信，从而减小网络开销，同时减少了STREAM线程启停开销； 大表、事实表，无合适分布列的表。