在实际的生产环境中，难免会出现一些突发情况，导致查询语句出现异常中断、阻塞时间长等情况，如果当时没能记录下来，那么事后就要投入更多的人力以及时间成本去对错误进行定位和解决，有时还往往定位不到错误出现的地方。为了解决这种情况，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线程启停开销； 大表、事实表，无合适分布列的表。 

表是数据库中最基础的对象，其设计的好坏直接决定后续业务的稳定性。表设计的关键在于存储方式、分布方式、分区策略的选择，这些选择均和业务特征强相关，要结合业务实际特征来设计。 当前表的主要存储类型即行存和列存，存储方式和业务特征决定了数据占用的空间、膨胀的速度、查询性能的优劣和稳定。 DML增删改：UPDATE和DELETE操作多的场景。 DML查询：点查询(返回记录少，基于索引的简单查询)。 DML查询：统计分析类查询(group , join的数据量大的场景)。 DML增删改：INSERT批量导入场景（单次单分区入库量接近或大于6w* DN数）。 DML查询：统计分析类查询(group , join的数据量大的场景)。 DML增删改：UPDATE/DELETE多的场景、INSERT小批量插入的场景DML查询：高并发的点查询

如果用户在APP的开发中，使用了连接池机制，那么需要遵循如下规范： 如果使用连接池，需要确保应用侧连接池的空闲超时时间配置要不长于DWS中，SESSION_TIMEOUT时间，或者连接池中连接建连后设置关闭SESSION_TIMEOUT，否则可能导致业务从连接池获取的连接已在DWS中超时退出，从而出现报错。 如果使用连接池中的连接并设置了GUC参数，那么在将连接归还连接池之前，必须使用“SET SESSION AUTHORIZATION DEFAULT;RESET ALL;”将连接的状态清空，否则连接被其他业务复用时，可能会出现性能、业务报错等各类问题。 如果使用连接池中的连接创建了临时表，那么在将连接归还连接池之前，必须手动删除临时表，否则连接被其他业务复用时，可能出现临时表创建报错问题（临时表为 session 级别对象，使用同一个连接池连接，相当于在同一个session，临时对象也不能重名）。 应用侧有使用连接池的场景，如果在DWS侧通过GS_GUC RELOAD设置了全局的GUC参数，需要重启应用侧连接池才能够享受该参数变化，因该设置只针对新建的连接生效，针对连接池中已有的老连接不生效。 在应用中的复杂作业和简单作业场景，建议单独划分连接池，避免作业间公共资源消耗的影响（如IDLE连接内存消耗）。 在应用侧连接数不受控的场景，可以借助连接池机制控制应用侧接入的的活跃会话数。

保证业务连接均匀分布到各CN，参考29.1.3配置负载均衡，避免单CN出现并发瓶颈； 应用程序使用连接完成作业任务之后，需及时主动CLOSED连接，避免IDLE空闲连接持续占位增长，导致无法新建连接； 应用程序尽量使用自动提交方式（默认autocommit），如需关闭 autocommi时则需应用程序确保事务手动提交，避免造成大量“idle in transaction”的连接； 引用通过JDBC连接数据库时，应该保证下面三个时区设置一致： a) JDBC客户端所在主机的时区。 b) GaussDB(DWS) Server所在主机的时区。 c) GaussDB(DWS)集群配置中时区（例如：SET TIME ZONE 'UTC-8'）。规划数据库用户是规划整个业务模型的一部分，建议根据各业务模块进行用户划分，合理的用户划分能够帮助DBA从服务侧更有效的区分业务优先级，以及不同业务类型的精确管控，同时便于做更精确的资源管控。

cm_ctl、gs_ctl、gs_om好像都可以管理集群，有什么区别啊，用哪个更好呀

以下是华为云GaussDB与PostgreSQL（pgsql）不一样的10个关键点总结：内核架构与模型GaussDB将PostgreSQL的进程模型改为线程池模型，降低了内存溢出风险，但牺牲了操作系统级进程终止的灵活性（如无法使用kill命令直接终止连接）。事务ID位数PostgreSQL使用32位事务ID，高并发场景下易耗尽（约12小时需执行VACUUM FREEZE）；GaussDB升级为64位事务ID，彻底解决该问题，支持无限事务处理。全局事务管理（GTM）GaussDB引入第三方etcd集群存储全局事务号，将GTM工作剥离，实现高可用强一致；PostgreSQL依赖GTM单节点或主备架构，存在性能瓶颈和单点故障风险。存储引擎多样性PostgreSQL仅支持行存储；GaussDB支持行存、列存及Ustore（混合存储），适应不同场景需求（如分析型查询用列存，事务型用行存）。分布式架构能力PostgreSQL原生支持单节点，需通过插件（如Citus）实现分布式；GaussDB企业版原生支持分布式架构，数据自动分片，支持跨地域集群部署。高可用与容灾PostgreSQL高可用依赖主备切换和第三方工具；GaussDB提供集群管理模块（CMS），支持故障自动切换、进程自愈，且主备切换后原主库可自动重建。并行查询优化PostgreSQL支持并行查询，但需手动配置；GaussDB在分布式架构下优化多节点并行查询，显著提升复杂查询性能。安全特性增强PostgreSQL提供基础安全机制（如SSL加密、行级访问控制）；GaussDB增加数据动态脱敏、全密态计算、防篡改等企业级安全特性，符合国密标准。跨版本与模式兼容PostgreSQL为单一数据库；GaussDB支持多模式（如Oracle兼容模式、MySQL兼容模式），便于异构数据库迁移，降低企业替换成本。商业支持与生态PostgreSQL依赖开源社区支持；GaussDB由华为提供企业级商业支持，包括定制化服务、性能调优、专属工具（如DRS数据迁移服务），适合大规模企业应用。

我想请问大佬，gs_dump备份可以对于一张表指定条件吗，我现在有一张300个分区的表，其实我只需要备份其中的15个分区，其余不需要备份

我想请问大佬，对于一张200G的大表，Drop它的xlog追平速度和Truncate它的xlog追平速度差别大吗，哪个快呢

如图所示，tpops已经订购容量了，但是现在想改成每主机的方式后重新申请。怎么做