在当今数字化时代，数据的存储和处理需求不断增长，企业对于数据库的性能和可扩展性要求也越来越高。华为云 GaussDB 作为一款高性能、高可靠的企业级分布式数据库，其弹性伸缩功能为用户提供了极大的便利和灵活性。今天，我们就来深入探讨一下华为云 GaussDB 的弹性伸缩原理。一、弹性伸缩的重要性随着业务的发展，数据库的负载可能会出现剧烈的波动。在高峰时期，数据库可能需要处理大量的并发请求，而在低谷时期，资源可能会处于闲置状态。弹性伸缩功能可以根据实际的负载情况自动调整数据库的资源配置，确保在任何时候都能提供高效的服务，同时避免资源的浪费。二、华为云 GaussDB 的弹性伸缩原理监控与评估 华为云 GaussDB 首先通过内置的监控系统对数据库的各项指标进行实时监测，包括 CPU 利用率、内存使用率、磁盘 I/O、网络流量等。这些指标可以反映数据库的负载情况和性能状态。同时，系统还会对历史数据进行分析，以预测未来的负载趋势。伸缩策略制定 基于监控和评估的结果，用户可以制定灵活的伸缩策略。例如，可以设置当 CPU 利用率超过一定阈值时自动增加节点，当内存使用率低于一定阈值时自动减少节点等。这些策略可以根据实际业务需求进行定制，以实现最佳的资源利用和性能表现。自动伸缩执行 当数据库的负载达到触发伸缩策略的条件时，华为云 GaussDB 会自动执行伸缩操作。如果需要增加节点，系统会快速启动新的数据库节点，并将其加入到数据库集群中。新节点会自动同步数据，并开始分担负载。如果需要减少节点，系统会选择合适的节点进行下线操作，并确保数据的完整性和一致性。负载均衡 在弹性伸缩过程中，华为云 GaussDB 还会通过内置的负载均衡机制确保数据的均匀分布和请求的合理分配。新加入的节点会自动接收一部分负载，而减少的节点上的负载会被重新分配到其他节点上。这样可以保证整个数据库集群始终处于高效的运行状态。三、弹性伸缩的优势高效应对业务变化 无论是业务的突然增长还是季节性波动，华为云 GaussDB 的弹性伸缩功能都能够快速响应，确保数据库的性能和可用性不受影响。降低成本 通过自动调整资源配置，用户可以避免在低负载时期过度配置资源，从而降低成本。同时，在高负载时期也能够及时增加资源，确保业务的正常运行。简化管理 弹性伸缩功能使得数据库的管理变得更加简单和自动化。用户无需手动干预资源的调整，只需设置好伸缩策略，系统就会自动根据负载情况进行调整。四、应用场景电商平台 在电商促销活动期间，订单量和用户访问量会大幅增加。华为云 GaussDB 的弹性伸缩功能可以确保数据库能够快速应对高并发的请求，提供稳定的服务。金融行业 金融交易系统对数据库的性能和可靠性要求极高。弹性伸缩功能可以在交易高峰时期提供足够的资源，保障交易的快速处理，同时在低峰时期降低成本。大数据分析 大数据分析任务通常需要大量的计算资源和存储容量。华为云 GaussDB 的弹性伸缩功能可以根据分析任务的规模自动调整资源，提高分析效率。

文章来自“Gauss松鼠会小助手2”至2024/9/30前的所有博客发贴1. DataKit数据迁移-3前置校验失败的处理https://bbs.huaweicloud.com/blogs/4322592. DataKit数据迁移-2实例搭建步骤https://bbs.huaweicloud.com/blogs/4322573. DataKit数据迁移-1使用说明https://bbs.huaweicloud.com/blogs/4322564. openGauss 6.0.0-RC1新特性：一站式交互安装初体验https://bbs.huaweicloud.com/blogs/4322545. GaussDB技术解读——GaussDB架构介绍（一）https://bbs.huaweicloud.com/blogs/4286536. 【酷哥说库|GaussDB微动画】GaussDB数据库两地三中心异地容灾解决方案https://bbs.huaweicloud.com/blogs/4277197. 【酷哥说库|GaussDB微动画】GaussDB数据库的分区表https://bbs.huaweicloud.com/blogs/4277088. 【酷哥说库|GaussDB微动画】GaussDB数据库的分区表https://bbs.huaweicloud.com/blogs/4270689. 【酷哥说库|GaussDB微动画】GaussDB数据库的分区表https://bbs.huaweicloud.com/blogs/42704710. GaussDB SQL基础语法示例-BOOLEAN表达式https://bbs.huaweicloud.com/blogs/42702711. GaussDB SQL基本语法示例-CASE表达式https://bbs.huaweicloud.com/blogs/42702312. 对GaussDB数据库和数据管理的简单介绍https://bbs.huaweicloud.com/blogs/42702213. GaussDB数据库特性-物化视图简介https://bbs.huaweicloud.com/blogs/42702114. GaussDB数据库SQL系列-LOCK TABLEhttps://bbs.huaweicloud.com/blogs/42702015. openGauss使用BenchmarkSQL进行性能测试https://bbs.huaweicloud.com/blogs/42658816. 【项目实战经验】基于openEuler22.03搭建openGauss Datakit 5.1.1https://bbs.huaweicloud.com/blogs/42624617. GaussDB数据库SQL系列-动态语句https://bbs.huaweicloud.com/blogs/42301218. GaussDB数据库SQL系列-游标管理https://bbs.huaweicloud.com/blogs/42223919. GaussDB数据库SQL系列-定义重载函数https://bbs.huaweicloud.com/blogs/41502720. GaussDB数据库SQL系列-自定义函数https://bbs.huaweicloud.com/blogs/41494921. GaussDB数据库SQL系列-SQL与ETL浅谈https://bbs.huaweicloud.com/blogs/41462322. GaussDB数据库SQL系列-数据去重https://bbs.huaweicloud.com/blogs/41461723. GaussDB数据库SQL系列-层次递归查询https://bbs.huaweicloud.com/blogs/41454524. GaussDB数据库SQL系列-行列转换https://bbs.huaweicloud.com/blogs/41454225. GaussDB数据库SQL系列-DROP & TRUNCATE & DELETEhttps://bbs.huaweicloud.com/blogs/41448626. GaussDB数据库SQL系列-子查询https://bbs.huaweicloud.com/blogs/41445427. GaussDB数据库SQL系列-UNION & UNION ALLhttps://bbs.huaweicloud.com/blogs/41435928. GaussDB数据库SQL系列-表连接（JOIN）https://bbs.huaweicloud.com/blogs/41390429. GaussDB数据库的元数据及其管理简介https://bbs.huaweicloud.com/blogs/41390230. GaussDB OLTP云数据库配套工具DRShttps://bbs.huaweicloud.com/blogs/41388031. GaussDB的行存表与列存表的选择https://bbs.huaweicloud.com/blogs/41390032. GaussDB云数据库配套工具UGOhttps://bbs.huaweicloud.com/blogs/41388333. GaussDB OLTP 云数据库配套工具DAShttps://bbs.huaweicloud.com/blogs/41388134. GaussDB OLTP云数据库配套工具DDMhttps://bbs.huaweicloud.com/blogs/41384535. 数据库模型设计案例分享（GaussDB版）https://bbs.huaweicloud.com/blogs/41384336. GaussDB云数据库SQL应用系列—分区表管理https://bbs.huaweicloud.com/blogs/41377537. GaussDB云数据库SQL应用系列—索引管理https://bbs.huaweicloud.com/blogs/41377338. GaussDB云数据库SQL应用系列-定时任务管理https://bbs.huaweicloud.com/blogs/41376439. GaussDB云数据库SQL应用系列-视图管理https://bbs.huaweicloud.com/blogs/41373240. JDBC连接GaussDB云数据库操作示例https://bbs.huaweicloud.com/blogs/41369441. GaussDB云数据库SQL应用系列-基础使用https://bbs.huaweicloud.com/blogs/41369242. GuassDB数据库的GRANT & REVOKEhttps://bbs.huaweicloud.com/blogs/41368943. GaussDB数据库基础函数介绍-下https://bbs.huaweicloud.com/blogs/41363044. GaussDB数据库基础函数介绍-上https://bbs.huaweicloud.com/blogs/41360345. GaussDB数据库事务介绍https://bbs.huaweicloud.com/blogs/41346746. GaussDB数据库存储过程介绍https://bbs.huaweicloud.com/blogs/41346547. GaussDB数据类型介绍https://bbs.huaweicloud.com/blogs/41346448. GaussDB数据类型转换介绍https://bbs.huaweicloud.com/blogs/413441GaussDB 干货汇总（上）文章来自“Gauss松鼠会小助手2”至2024/8/30前的所有论坛发帖https://bbs.huaweicloud.com/blogs/431800

密态等值查询属于密态数据库第一阶段方案，但是遵从密态数据库总体架构。密态数据库的总体架构示意图如下图所示。密态数据库的完整形态包括密码学方案和软硬结合方案。从总体流程上来看，数据在客户端完成加密，以密文形式发送到GaussDB Kernel数据库服务侧，即需要在客户端构建加解密模块。加解密模块依赖密钥管理模块，密钥管理模块生成根密钥(RK, Root Key)和客户端主密钥(CMK，Client Master Key)，有了CMK，可以通过SQL语法定义列加密密钥(CEK，Column Encryption Key)。其中，CMK由RK加密后保存在密钥存储文件(KSF，Key Store File)中，与RK一起由KeyTool统一管理；CEK则由CMK加密后存储在服务端，加密算法使用AES128和AES256。按照原有明文格式发送至服务端。当查询任务发起后，客户端需要对当前的Query进行解析，如果查询语句中涉及加密列，则对对应的列参数(加密列关联参数)也要进行加密(这里说的加密均需要为确定性加密，否则无法支持对应的查询)；如果查询语句中不涉及加密列，则直接发送至服务端，无需额外的操作。在数据库服务侧，加密列的数据始终以密文形态存在，整个查询也在密文形态下实现。对于第一阶段密态等值查询解决方案，需要采用确定性加密，使得相同的明文数据获得相同的密文，从而支持等值计算。按照用户使用的流程，整体设计思路将围绕用户的使用步骤展开，即整个Use Case被切分成三部分。具体如下：生成客户端主密钥：用户需要在本地部署密钥管理工具（KeyTool），通过密钥管理工具相关指令来管理密钥，如创建或删除密钥；当前该工具底层集成华为公司KMC组件，生成的主密钥通过KMC进行保存和管理，并返回密钥信息给用户，方便后续调用和管理；记录CMK与CEK信息，在系统创建加密表：有了阶段1中生成的密钥信息后，为数据库设计专门的密钥创建语法，包括设计新的主密钥(CMK, Client Master Key)和列加密密钥(CEK, Column Encryption Key)语法；通过内核接口访问KeyTool中存储的主密钥并记录在系统中，列加密密钥则由主密钥在客户端完成加密后存储在数据库服务端；数据通过列加密密钥完成在客户端的加密，然后传输到服务端。为了做到查询对用户的透明，需要基于当前已有的创建表语法进行改造，主要进一步增强列的option信息；完成密态等值查询：为了完成密态等值查询需要在客户端和服务端完成配合设计。其中在客户端需要设计轻量级的解析模块，完成对查询语句的解析，定义密态等值查询所支持的规格。在客户端解析模块，需要识别所有涉及的属性是否包含加密列信息，如果不涉及则直接返回并将查询发送到服务端，如果涉及加密列，则需要按照对应的列加密密钥和加密算法加密参数信息，然后发送查询任务到服务端。在服务端，需要在优化器和执行器的各个执行逻辑过程中完成功能适配，特别的，数据在经过加密后，存储的数据类型发生变更，在服务端需要根据新的存储类型进行查询任务执行。

在gsql命令方式中，使用\copy导入CSV文件的任意几列数据，如何实现？请教各位老师。

GaussDB是一款华为公司开发的关系型数据库管理系统（RDBMS），提供了多种数据类型用于存储和处理不同类型的数据。以下是GaussDB常见的数据类型：1、GaussDB常见的数据类型 1.1、数值型（Numeric Types）：整型（Integer）：INT小数型（Decimal）：DECIMAL 1 21.2、字符型（Character Types）：字符串（String）：CHAR、VARCHAR、TEXT、CLOB二进制数据（Binary Data）：BINARY、VARBINARY、BLOB 1 21.3、时间型（Date and Time Types）：日期（Date）：DATE时间（Time）：TIME时间戳（Timestamp）：TIMESTAMP 1 2 31.4、布尔型（Boolean Type）：布尔值（Boolean）：BOOLEAN 11.5、大整数（Big Integer）：大整数（Bigint）：BIGINT 11.6、浮点型（Floating-Point Types）：单精度浮点数（Float）：FLOAT双精度浮点数（Double）：DOUBLE 1 21.7、其他类型：XML：XMLJSON：JSON数组：ARRAY 1 2 3 2、GaussDB常用的DDL语句2.1、创建数据库 CREATE DATABASE database_name WITH OWNER = my_user TEMPLATE = template0 ENCODING = 'UTF8' LC_COLLATE = 'en_US.UTF-8' LC_CTYPE = 'en_US.UTF-8'; 1 2 3 4 5 6 WITH OWNER：指定数据库的所有者，即拥有该数据库的用户。 TEMPLATE：指定用作新数据库模板的现有数据库。在这个示例中，我们使用 template0 作为模板。 ENCODING：指定数据库的字符集。在这个示例中，我们使用 UTF8 字符集。 LC_COLLATE：指定数据库的排序规则，即字符串比较的规则。在这个示例中，我们使用 en_US.UTF-8 排序规则。 LC_CTYPE：指定数据库的字符分类规则，用于字符的分类和转换。 2.2、删除数据库 DROP DATABASE database_name; 1 2.3、创建表 CREATE TABLE table_name ( column1 datatype, column2 datatype, ... ); 1 2 3 4 5 2.4、修改表 2.4.1、添加列 ALTER TABLE table_name ADD column_name datatype; 1 2.4.2、修改列数据类型 ALTER TABLE table_name ALTER COLUMN column_name TYPE new_datatype; 1 2.4.3、修改列名 ALTER TABLE table_name RENAME COLUMN old_column_name TO new_column_name; 1 2.4.4、删除列 ALTER TABLE table_name DROP COLUMN column_name; 1 2.4.5、修改表名 ALTER TABLE table_name RENAME TO new_table_name; 1 2.5、删除表 DROP TABLE table_name; 1 2.6、创建索引 CREATE INDEX index_name ON table_name (column1, column2, ...); 1 2.7、删除索引 DROP INDEX index_name; 1 2.8、添加表注释 COMMENT ON TABLE table_name IS 'Your comment here'; 1 2.9、添加列注释 COMMENT ON COLUMN table_name.column_name IS 'Your comment here'; ———————————————— 版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。 原文链接：cid:link_0

GaussDB常见调优指南一. Analyze 统计信息解析 前言 适用版本：【8.1.1 及以上】本文简单介绍什么是统计信息、统计信息记录了什么、为什么要收集统计信息、怎么收集统计信息以及什么时候收集统计信息。 WHY：为什么需要统计信息Query 执行流程 词法&语法解析 语义解析 查询重写 查询优化 查询执行CBO 模型 通过代价模型(Cost Model)和统计信息估算每种执行方式的代价，然后选择一种执行代价最优的执行方式。WHAT：都有哪些统计信息 统计信息包括表记录条数、页面数、MCV(高频非 NULL 值)、HISTOGRAM（直方图）、CORRELATION 等。WHERE：统计信息在哪里 统计信息存储在系统表 pg_class 和 pg_statistic 中。HOW：如何生成统计信息 可以通过以下命令手动收集统计信息：ANALYZE [ VERBOSE ] [ table_name [ ( column_name [, ...] ) ] ]; 1 也可以通过配置参数 default_statistics_target 提升统计信息质量，或开启 autoanalyze 自动收集统计信息。WHEN：什么时候收集统计信息 大规模数据变化或查询新增数据时需要收集统计信息。WHO：谁来收集统计信息 建议在业务开发过程中，根据数据变化量和查询特征主动对相关表做 Analyze。总结 本文简单介绍了统计信息的含义及其在性能调优中的重要作用，详细说明了统计信息的内容、存储位置以及如何有效收集统计信息的方法。二. Explain 分布式计划解析 前言 适用版本：【8.1.1 及以上】本文介绍如何详细解读计划以及计划的执行过程，从中发现可能存在的性能瓶颈点及其产生的原因。执行算子介绍 常用的执行算子包括：扫描算子：SeqScan, Indexscan, IndexOnlyScan, BitmapScan, SubqueryScan, 等。 连接算子：NestLoop, MergeJoin, HashJoin。 物化算子：Material, Sort, Group, Agg, WindowAgg, Unique, Hash。 控制类算子：ModifyTable, Append, MergeAppend, RecursiveUnion, BitmapAnd, BitmapOr, 等。 Stream 算子：Gather Stream, Redistribute Stream, Broadcast Stream。 Explain 用法 使用 explain 命令可以查看优化器为每个查询生成的具体执行计划。 示例计划解读 通过具体示例说明不同类型的计划和算子的资源消耗、耗时等信息。总结 在调优过程中，熟练使用 Explain 并能分析各部分数据结果是非常重要的。三. 性能调优总体策略详解 前言 适用版本：【8.1.1 及以上】性能调优是应用迁移或开发过程中的关键步骤，需要贯穿于整个项目实施过程中。GaussDB(DWS)执行架构及说明 GaussDB(DWS)是典型的 share-nothing 架构，主要由 CN（Coordinator）和 DN（DataNode）组成。整体调优思路 调优过程包括数据模型建模、集群部署、表结构设计、SQL 语句优化等多个方面。性能瓶颈诊断 GaussDB(DWS)提供了丰富的计划信息显示工具 Explain 和动态执行信息分析工具 Top SQL，用于诊断性能瓶颈。性能原因分析 性能原因分析需要对数据库的执行实现原理有基本了解。GaussDB(DWS)基于代价生成计划，统计信息是计划准确的前提。调优项实施 调优项包括系统级调优和语句级调优。四. 性能调优之坏味道 SQL 识别 前言 适用版本：【8.1.1 及以上】本文介绍如何识别和优化坏味道 SQL。简单实例 通过具体实例说明坏味道 SQL 的识别方法。识别 SQL 坏味道之自诊断视图 通过自诊断视图识别 SQL 坏味道。发现正在运行的 SQL 的坏味道 利用 Top SQL 工具发现正在运行的 SQL 的坏味道。总结 本文介绍了如何识别和优化坏味道 SQL，以提高数据库性能。五. 性能调优之好味道表定义 前言 适用版本：【8.1.1 及以上】本文介绍如何定义表结构以优化性能。存储方式设计 选择合适的存储方式以提高性能。数据分布方式设计 设计合理的数据分布方式以优化性能。分布列设计 合理设计分布列以提高查询性能。表分区设计 通过表分区设计优化性能。字段设计 合理设计字段以提高性能。约束设计 通过设计约束提高数据完整性和查询性能。总结 本文介绍了如何通过合理设计表结构来优化性能。六. 性能调优之 SQL 改写 前言 适用版本：【8.1.1 及以上】本文介绍如何通过改写 SQL 提高性能。不支持下推导致的坏味道 识别并优化不支持下推的 SQL。不支持重分布导致的坏味道 识别并优化不支持重分布的 SQL。数据类型转换导致的坏味道 避免不必要的数据类型转换。全局性操作导致的坏味道 优化全局性操作以提高性能。NestLoop 类低效运算导致的坏味道 避免使用低效的 NestLoop 连接。冗余操作导致的坏味道 去除冗余操作以优化性能。总结 本文介绍了如何通过改写 SQL 提高性能。七. 性能调优之路径干预 前言 适用版本：【8.1.1 及以上】本文介绍如何通过路径干预提高性能。cost 模型选择 选择合适的 cost 模型以优化性能。Scan 方式的选择 选择合适的扫描方式以提高性能。关联方式的选择 选择合适的关联方式以优化性能。Stream 方式的选择 选择合适的 Stream 方式以优化性能。总结 本文介绍了如何通过路径干预提高性能。 ———————————————— 版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。 原文链接：cid:link_0

用户接口层在用户接口层，实现SQL-like语法，提供Create Model、Predict等关键字，支持AI算法训练和预测。当前支持的AI算法包括：GD（梯度下降法）、KMeans（聚类）、XGBoost、决策树等。查询优化层查询优化层提供AI训练执行计划和AI预测执行计划，该计划依据内部统计信息和AI算子调用关系，生成相应执行计划。可以把AI算子看做执行器中的计算单元，例如Join、AGG等，AI算子执行代价基于执行逻辑、获取的数据行数、算法复杂度共同决定。同时在执行计划生成后，可通过Explain语句查看详细的执行开销，分析路径选型的正确性。AI底座和执行层在AI底座中，提供超参优化能力，即用户不指定超参数或者指定超参数的范围，自动选择适合的参数，该功能极大提升用户使用的效率，同时达到最佳的训练性能。在执行器中，提供多种AI算子，例如GD算子可支持逻辑回归、分类；KMeans算子支持聚类。在每个算子实现过程中，遵循执行器算子实现逻辑，下层对接Scan算子，上次提供AI算子的训练或推理结果。在训练完成后，训练模型将实时保存到系统表中，用户可以查询gs_model_warehouse系统表来获取模型信息。存储层在存储层，DB4AI提供数据集管理功能，即用户可以抽取某个表或多个表中的列信息，组成一个数据集，用于后续模型训练。数据集管理功能类似git模式提供多版本管理，目的是保障训练数据的一致性。同时在这过程中，可通过特征处理和数据清洗保障数据的可用性。同时对已生成的模型进行管理，包括模型评估、定期模型验证、模型导入、模型导出等能力，在验证模型失效后，模型漂移功能可以进行模型刷新，保障模型可用。异构计算层DB4AI框架支持异构计算层，实现CPU和AI算力的统一调度，满足数据库语句执行和AI训练的完美结合。在实现方面，CPU算力，特指ARM及X86芯片，可用于基础机器学习算子调用及并行计算执行；AI算子，例如昇腾及GPU芯片，可用于重度分析算子（Join、AGG）及深度学习算子使用，加速大数据及多层网络场景下计算需求。 ———————————————— 版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。 原文链接：cid:link_0

智能关键技术一：自治运维系统 GaussDB 自治运维系统“DBMind”的整体系统框图如下图所示，包含四个维度：数据采集层数据采集层主要功能实现指标数据采集，采集频率分为秒级采集和分钟级采集。其中秒级采集包括操作系统资源信息采集和数据库实例信息采集，例如操作系统层面CPU、内存、IO读写、网络资源信息采集，数据库实例状态、数据库内关键指标（内存、连接数、TPS、QPS、读写频率等）；分钟级采集包括审计日志采集、数据库日志采集和全量SQL流水采集。DBMind数据平台提供Agent进程用于采集上述指标；若客户系统配置普罗米修斯进行信息采集，DBMind提供openGauss-exporter，内置数据库多维度指标采集以及二次数据计算，实现与用户既有普罗米修斯平台对接。数据库采集端程序需要部署在同数据库物理机节点，数据库多节点集群环境中，每个物理节点部署一个Agent采集端（或者普罗米修斯采集端）。数据库采集端程序通常占用资源很少，通过配置文件可以制定不同指标采集频率，以免占用资源影响数据库业务正常运行。数据计算层数据计算层提供数据存储、数据分析及元数据管理能力。其中数据存储用于接收来自数据采集层发生来的数据，存储数据源可以是多种维度或者类型，包括普罗米修斯、时序数据库（OpenTSDB）、MongoDB、SQLite等，DBMind内置对接接口，AI模块与存储数据源的交互，获取数据并进行处理。DBMind默认提供SQLite数据库，方便普通开发者来使用AI自治功能；在企业业务中，存储层设计要复杂的多，可以使用多个开源组件组合使用，例如普罗米修斯+时序数据库，或者kafka+时序数据库等多种方案。使用nginx进行业务分流，mgrsrv服务对数据进行初步处理后，将数据写入关系型数据库。基于可靠性考虑，对于三个组件，分别加入备机进行可靠性保护。若企业业务处理上万业务节点的数据，图2方案无法满足客户业务诉求。故在方案设计时，需要引入分布式消息中间件、数据库中间件（DDM），同时因为nginx挂载节点有上限，需要对mgrsvr进行分区管理。consumer服务可以和mgrsvr部署在同一个节点上，mq集合代表分布式消息中间件，通常可以采用开源软件rocketmq或者rabbitmq，引入消息中间件目的是降低目标数据库的压力。DDM是华为云的数据库中间件，若采用开源软件，也可使用mycat或者dble等，可进行存储大规模被采集的数据。在整体业务角度，纵向通过分层设计，横向通过分区设计，保证全部业务可通过管控层完成数据处理。在数据计算层除了时序存储数据库外，还可以设计其他存储单元，例如算法模型库和故障规则库。其中算法模型库存储自治管理服务生成的AI模型，例如参数推荐训练模型；在算法模型库中，可以存储传统机器学习（例如监督学习）模型、强化学习模型。故障规则库是记录数据库常见故障案例，将这些案例通过拆解和分析，生成规则引擎。自治服务层包含三个主要部分：SQL诊断和调优、自治安全、数据库智能运维。其中SQL诊断和调优提供多种SQL治理和调优能力，包括慢SQL发现、SQL表现评估、智能索引推荐、智能查询重写等服务。自治安全通过AI技术实现敏感信息发觉、SQL注入检测和异常行为分析。数据库智能运维功能实现在数据库系统、OS系统和数据库集群层面的运维和调优，其中数据库系统服务包括数据库参数智能推荐、智能巡检、数据库分布键推荐和智能业务调度；在操作系统层面，实现慢盘检测和恢复、网络丢包检测；在数据库集群层面，基于故障或者负载需求，提供自动扩缩容、异常节点修复服务。DBMind提供监控展示层，通过WEB形式，方便用户直观感受运维管理带来的遍历。在展示界面方面，集成Grafana实现实施数据或指标的展示，同时AI趋势预测，给出后续时段的数据走向。告警界面展示系统中可能存在的问题或故障，分为致命、严重、一般，界面中只显示致命问题。为方便用户系统观察集群状态，提供健康指数报告和详细综合报告。健康指数报告给出当前系统的健康评分等级，默认80分以上属于运行健康状况，小于60分则存在严重隐患，急需修复。综合报告详细描述系统各维度信息，包括集群状态、负载运行情况、常见数据库指标项信息。

本文作者： 向日葵执行计划 以如下SQL语句为例： select cjxh, count(1) from dwcjk group by cjxh; 执行EXPLAIN的输出为： 执行计划字段解读（横向）： ● id：执行算子节点编号。 ● operation：具体的执行节点算子名称。 Vector前缀的算子是指向量化执行引擎算子，一般出现含有列存表的Query中。 Streaming是一个特殊的算子，它实现了分布式架构的核心数据shuffle功能， Streaming共有三种形态，分别对应了分布式结构下不同的数据shuffle功能： – Streaming (type: GATHER)：作用是coordinator从DN收集数据。 – Streaming(type: REDISTRIBUTE)：作用是DN根据选定的列把数据重分布到 所有的DN。 – Streaming(type: BROADCAST)：作用是把当前DN的数据广播给其他所有的 DN ● E-rows：每个算子估算的输出行数。 ● E-memory：DN上每个算子估算的内存使用量，只有DN上执行的算子会显示。某 些场景会在估算的内存使用量后使用括号显示该算子在内存资源充足下可以自动 扩展的内存上限。 ● E-width：每个算子输出元组的估算宽度。 ● E-costs：每个算子估算的执行代价。 – E-costs是优化器根据成本参数定义的单位来衡量的，习惯上以磁盘页面抓取 为1个单位， 其它开销参数将参照它来设置。 – 每个节点的开销（E-costs值）包括它的所有子节点的开销。 – 开销只反映了优化器关心的东西，并没有把结果行传递给客户端的时间考虑 进去。虽然这个时间可能在实际的总时间里占据相当重要的分量，但是被优 化器忽略了，因为它无法通过修改规划来改变。 执行计划层级解读（纵向）：第一层：CStore Scan on dwcjk 表扫描算子，用CStore Scan的方式扫描表dwcjk。这一层的作用是把表dwcjk的数 据从buffer或者磁盘上读上来输送给上层节点参与计算。 第二层：Vector Hash Aggregate 聚合算子，作用是把下层计算输送上来的算子做聚合操作(group by)。 第三层：Vector Streaming (type: GATHER) Shuffle算子，此处GATHER类型的Shuffle算子作用是把数据从DN汇聚到CN。 第四层：Row Adapter 存储格式转化算子，主要作用是把内存中列式格式数据转为行式数据，以便客户 端展示。 需要注意的是最顶层算子为Data Node Scan时，需要设置 enable_fast_query_shipping为off才能看到具体的执行计划，如下面这个计划： openGauss=# explain select cjxh, count(1) from dwcjk group by cjxh; QUERY PLAN Data Node Scan (cost=0.00…0.00 rows=0 width=0) Node/s: All datanodes (2 rows) 设置enable_fast_query_shipping参数之后，执行计划显示如下： 图片.png 执行计划中的关键字说明：表访问方式 – Seq Scan 全表顺序扫描。 – Index Scan 优化器决定使用两步的规划：最底层的规划节点访问一个索引，找出匹配索 引条件的行的位置，然后上层规划节点真实地从表中抓取出那些行。独立地 抓取数据行比顺序地读取它们的开销高很多，但是因为并非所有表的页面都 被访问了，这么做实际上仍然比一次顺序扫描开销要少。使用两层规划的原 因是，上层规划节点在读取索引标识出来的行位置之前，会先将它们按照物 理位置排序，这样可以最小化独立抓取的开销。 如果在WHERE里面使用的好几个字段上都有索引，那么优化器可能会使用索 引的AND或OR的组合。但是这么做要求访问两个索引，因此与只使用一个索 引，而把另外一个条件只当作过滤器相比，这个方法未必是更优。 索引扫描可以分为以下几类，他们之间的差异在于索引的排序机制。 ▪ Bitmap Index Scan 使用位图索引抓取数据页。 ▪ Index Scan using index_name 使用简单索引搜索，该方式表的数据行是以索引顺序抓取的，这样就令 读取它们的开销更大，但是这里的行少得可怜，因此对行位置的额外排 序并不值得。最常见的就是看到这种规划类型只抓取一行，以及那些要 求ORDER BY条件匹配索引顺序的查询。因为那时候没有多余的排序步 骤是必要的以满足ORDER BY。 表连接方式 – Nested Loop 嵌套循环，适用于被连接的数据子集较小的查询。在嵌套循环中，外表驱动 内表，外表返回的每一行都要在内表中检索找到它匹配的行，因此整个查询 返回的结果集不能太大（不能大于10000），要把返回子集较小的表作为外 表，而且在内表的连接字段上建议要有索引。 – (Sonic) Hash Join 哈希连接，适用于数据量大的表的连接方式。优化器使用两个表中较小的 表，利用连接键在内存中建立hash表，然后扫描较大的表并探测散列，找到 与散列匹配的行。Sonic和非Sonic的Hash Join的区别在于所使用hash表结构 不同，不影响执行的结果集。 – Merge Join 归并连接，通常情况下执行性能差于哈希连接。如果源数据已经被排序过， 在执行融合连接时，并不需要再排序，此时融合连接的性能优于哈希连接。 运算符 – sort 对结果集进行排序。 – filter EXPLAIN输出显示WHERE子句当作一个"filter"条件附属于顺序扫描计划节 点。这意味着规划节点为它扫描的每一行检查该条件，并且只输出符合条件 的行。预计的输出行数降低了，因为有WHERE子句。不过，扫描仍将必须访 问所有 10000 行，因此开销没有降低；实际上它还增加了一些（确切的说， 通过10000 * cpu_operator_cost）以反映检查WHERE条件的额外CPU时间。 – LIMIT LIMIT限定了执行结果的输出记录数。如果增加了LIMIT，那么不是所有的行 都会被检索到。

问题描述 服务器卡顿的厉害，xshell工具不能访问，联系服务器管理员后，其对服务器进行了重启，恢复访问后查看集群状态显示状态异常，出现了CN服务异常告警，查询集群状态， CN组件状态为Deleted。 详情如下：--查看集群状态 [omm@node01 ~]$ cm_ctl query -Cvipd [ CMServer State ]node node_ip instance state1 192.168.30.51 192.168.30.51 1 /gaussdb/cluster/data/cm/cm_server Primary 2 192.168.30.52 192.168.30.52 2 /gaussdb/cluster/data/cm/cm_server Standby 3 192.168.30.53 192.168.30.53 3 /gaussdb/cluster/data/cm/cm_server Standby[ ETCD State ]node node_ip instance state1 192.168.30.51 192.168.30.51 7001 /gaussdb/cluster/data/etcd StateFollower 2 192.168.30.52 192.168.30.52 7002 /gaussdb/cluster/data/etcd StateFollower 3 192.168.30.53 192.168.30.53 7003 /gaussdb/cluster/data/etcd StateLeader[ Cluster State ]cluster_state : Degraded 降级 redistributing : No balanced : No current_az : AZ_ALL[ Coordinator State ]node node_ip instance state1 192.168.30.51 192.168.30.51 5001 8000 /gaussdb/cluster/data/cn Deleted 2 192.168.30.52 192.168.30.52 5002 8000 /gaussdb/cluster/data/cn Normal 3 192.168.30.53 192.168.30.53 5003 8000 /gaussdb/cluster/data/cn Deleted[ Central Coordinator State ]node node_ip instance state2 192.168.30.52 192.168.30.52 5002 /gaussdb/cluster/data/cn Normal[ GTM State ]node node_ip instance state sync_state1 192.168.30.51 192.168.30.51 1001 /gaussdb/cluster/data/gtm P Primary Connection ok Sync 2 192.168.30.52 192.168.30.52 1002 /gaussdb/cluster/data/gtm S Standby Connection ok Sync 3 192.168.30.53 192.168.30.53 1003 /gaussdb/cluster/data/gtm S Standby Connection ok Sync[ Datanode State ]node node_ip instance state | node node_ip instance state | node node_ip instancestate1 192.168.30.51 192.168.30.51 6001 33100 /gaussdb/cluster/data/dn/dn_6001 P Primary Normal | 2 192.168.30.52 192.168.30.52 6002 33100 /gaussdb/cluster/data/dn/dn_6002 S Standby Normal | 3 192.168.30.53 192.168.30.53 6003 33100 /gaussdb/cluster/data/dn/dn_6003S Standby Normal 2 192.168.30.52 192.168.30.52 6004 33120 /gaussdb/cluster/data/dn/dn_6004 P Standby Normal | 1 192.168.30.51 192.168.30.51 6005 33120 /gaussdb/cluster/data/dn/dn_6005 S Primary Normal | 3 192.168.30.53 192.168.30.53 6006 33120 /gaussdb/cluster/data/dn/dn_6006S Standby Normal 3 192.168.30.53 192.168.30.53 6007 33140 /gaussdb/cluster/data/dn/dn_6007 P Primary Normal | 2 192.168.30.52 192.168.30.52 6008 33140 /gaussdb/cluster/data/dn/dn_6008 S Standby Normal | 1 192.168.30.51 192.168.30.51 6009 33140 /gaussdb/cluster/data/dn/dn_6009S Standby Normal 连接工具也只能访问30.52节点，访问30.51和30.53节点提示如下报错：问题原因 可能原因有以下： 1、 虚拟机重启，断网等故障导致CN被剔除。 2、 CN与主DN断连导致CN被剔除。 3、 CN组件Down导致CN被剔除。 4、 CN组件频繁重启导致CN被剔除。 5、 CN组件被主动剔除。分析过程 build相关日志路径：$GAUSSLOG/bin/gs_ctlcm_agent日志路径：$GAUSSLOG/cm实例日志路径：$GAUSSLOG/gs_log/dn_xxcn日志路径：$GAUSSLOG/gs_log/cn_5001系统日志（仅root用户）：/var/log/message查看磁盘空间 df -h 查看磁盘空间，3个节点磁盘空间剩余还有不少。查询集群状态 登录任一节点，切换到数据库用户，查询集群状态 ，集群状态变成了Cluster State：Degraded，30.51和30.53节点上的CN节点被剔除，状态变成了Deleted。su - omm cm_ctl query -Cvipd 输出如下：[ CMServer State ]node node_ip instance state1 192.168.30.51 192.168.30.51 1 /gaussdb/cluster/data/cm/cm_server Primary 2 192.168.30.52 192.168.30.52 2 /gaussdb/cluster/data/cm/cm_server Standby 3 192.168.30.53 192.168.30.53 3 /gaussdb/cluster/data/cm/cm_server Standby ...... [ Cluster State ]cluster_state : Degraded redistributing : No balanced : No current_az : AZ_ALL[ Coordinator State ]node node_ip instance state1 192.168.30.51 192.168.30.51 5001 8000 /gaussdb/cluster/data/cn Deleted 2 192.168.30.52 192.168.30.52 5002 8000 /gaussdb/cluster/data/cn Normal 3 192.168.30.53 192.168.30.53 5003 8000 /gaussdb/cluster/data/cn Deleted ...... 查看主节点的cm_server日志 登录到CMS主节点查集群状态获取主节点信息 任一个节点登录到CMS主节点(显示节点30.51的实例状态是Primary)，查看cm_server日志。 CMS主节点，可通过查询集群状态获取 。su - omm cm_ctl query -Cv 输出如下：[omm@node01 ~]$ cm_ctl query -Cv [ CMServer State ]node instance state1 192.168.30.51 1 Primary --显示节点30.51的实例状态是Primary 2 192.168.30.52 2 Standby 3 192.168.30.53 3 Standby ...... 查看主节点的cm_server日志 打开对应时间点的cm_server-.log日志，如对应时间点的日志已被压缩，则查看对应的cm_server-*.log.gz日志。su - omm cd $GAUSSLOG/cm/cm_server vi cm_server-2024-08-26_100433-current.log 输出如下：2024-08-26 11:32:58.134 tid=24745 Monitor ASYN LOG: instance(5001) heartbeat timeout, heartbeat:6191, threshold:6 2024-08-26 11:32:58.134 tid=24745 Monitor ASYN LOG: instance(5003) heartbeat timeout, heartbeat:6191, threshold:6 2024-08-26 11:32:58.143 tid=24759 AGENT_WORKER ASYN LOG: instance(node =1 instanceid =5001) is not in normal status(db_state=18 status=5) 2024-08-26 11:32:58.567 tid=24758 AGENT_WORKER ASYN LOG: instance(node =3 instanceid =5003) is not in normal status(db_state=18 status=5) 2024-08-26 11:32:58.577 tid=24770 STORAGE ASYN LOG: [ReadOnlyActRecordInitState] instance 5001 in the initial state, disk_usage:8, read_only:0, read_only_threshold:85 2024-08-26 11:32:59.144 tid=24759 AGENT_WORKER ASYN LOG: instance(node =1 instanceid =5001) is not in normal status(db_state=18 status=5) 2024-08-26 11:32:59.568 tid=24758 AGENT_WORKER ASYN LOG: instance(node =3 instanceid =5003) is not in normal status(db_state=18 status=5) 2024-08-26 11:33:00.144 tid=24759 AGENT_WORKER ASYN LOG: instance(node =1 instanceid =5001) is not in normal status(db_state=18 status=5) 2024-08-26 11:33:00.569 tid=24758 AGENT_WORKER ASYN LOG: instance(node =3 instanceid =5003) is not in normal status(db_state=18 status=5) 2024-08-26 11:33:01.146 tid=24759 AGENT_WORKER ASYN LOG: instance(node =1 instanceid =5001) is not in normal status(db_state=18 status=5) 2024-08-26 11:33:01.571 tid=24758 AGENT_WORKER ASYN LOG: instance(node =3 instanceid =5003) is not in normal status(db_state=18 status=5) 2024-08-26 11:33:02.146 tid=24759 AGENT_WORKER ASYN LOG: instance(node =1 instanceid =5001) is not in normal status(db_state=18 status=5) 2024-08-26 11:33:02.570 tid=24758 AGENT_WORKER ASYN LOG: instance(node =3 instanceid =5003) is not in normal status(db_state=18 status=5) 场景1：cm_server日志中搜索有关键词cn_down_to_delete=1 在cm_server日志中搜索有关键词cn_down_to_delete=1: ● 如对应时间点存在该信息，则原因为CN组件Down 导致，参考CN状态Down排查详细原因。 ● 确认故障节点是否发生断网。 ● 确认故障节点操作系统是否发生过重启。 ● 故障处理后执行节点修复加回被剔除的CN。 ● 如不涉及继续场景2。场景2：cm_server日志中搜索有关键词isCnDnDisconnected=1 在cm_server日志中搜索有关键词： isCnDnDisconnected=1： ● 如对应时间点存在该信息，则原因为CN组件与主DN断链导致，此时需要排查CN与主DN之间的网络，待网络恢复后，执行节点修复加回被剔除的CN。 ● 如不涉及继续场景3。场景3：cm_server日志中搜索有关键词cmd_disable_cn=1 在cm_server日志中搜索有关键词： cmd_disable_cn=1： ● 如对应时间点存在该信息，则原因为CN组件被主动剔除，确认剔除原因后，后执行节点修复加回被剔除的CN。 ● 如不涉及继续场景4。场景4：cm_server日志中搜索有关键词cnReadonly=1 在cm_server日志中搜索有关键词： cnReadonly=1： ● 如对应时间点存在该信息，则原因为CN组件readonly 导致，参考CN状态为readonly排查详细原因。 ● 如不涉及继续场景5。场景5：cm_server日志中搜索有关键词cn instance restarts within ten minutes is more than 在cm_server日志中搜索有关键词” cn instance restarts within ten minutes is more than”： ● 如对应时间点存在此信息，则原因为CN组件频繁重启导致，出现此种情况，参考 CN 启动失败进一步定位，故障处理后执行节点修复加回被剔除的CN。 ● 如不涉及继续场景6场景6：联系华为工程师提供技术支持若以上均不涉及，则联系华为工程师提供技术支持本文档属于场景6的情况。解决办法 修复CN 分别在已剔除的CN节点上操作，修复过程会有些漫长，大概5分钟左右--192.168.30.51上执行 gs_replace -t config -h 192.168.30.51 #修复CN组件 gs_replace -t start -h 192.168.30.51 #启动CN组件--192.168.30.53上执行 gs_replace -t config -h 192.168.30.53 #修复CN组件 gs_replace -t start -h 192.168.30.53 #启动CN组件 以192.168.30.51为例，输出如下：--修复CN [omm@node01 cn_5001]$ gs_replace -t config -h 192.168.30.51 Start checking bin files on node:['192.168.30.51'] checked bin files on node:[192.168.30.51], output:Success Check the etcd health. ETCD normal count:3 Check the number of abnormal ETCD is completed. Fixing ETCD instances. Fixing all the CMAgents instances. There are [0] CMAgents need to be repaired in cluster. There are [0] GNS need to be repaired in cluster. Update resource control config file: Not found resource config file on this node. Check stop resume file failed. Fresh cluster status successfully. Checking replace condition. Check the etcd health. ETCD normal count:3 Check the number of abnormal ETCD is completed. Successfully checked replace condition. Waiting for promote peer instances. . Successfully upgraded standby instances. Scp obs server key file to warmstandby node. Generate server key file succeed. Configuring replacement instances. Successfully configured replacement instances. Deleting abnormal CN from pgxc_node on the normal CN. No abnormal CN needs to be deleted. Unlocking cluster. Successfully unlocked cluster. Locking cluster. Successfully locked cluster. Incremental building CN from the Normal CN. Successfully incremental built CN from the Normal CN. Creating deleted CN on the normal CN. No CN needs to be created. Setting the SCTP. Successfully set the SCTP. Start to update_cn_status_to_normal_on_etcd. Successfully update_cn_status_to_normal_on_etcd. Unlocking cluster. Successfully unlocked cluster. Configuration succeeded. Successfully do action: config.--启动CN组件 [omm@node01 cn_5001]$ gs_replace -t start -h 192.168.30.51 Starting. ======================================================================Successfully started instance process. Waiting to become Normal.====================================================================== Start succeeded on all nodes. Start succeeded. Successfully do action: start. 查集群状态 查集群状态，集群状态已经由degraded变成了Noraml，CN组件状态也由Deleted变成了Noraml，任一个节点操作即可。cm_ctl query -Cvipd 输出如下：[omm@node01 ~]$ cm_ctl query -Cvipd [ CMServer State ]node node_ip instance state1 192.168.30.51 192.168.30.51 1 /gaussdb/cluster/data/cm/cm_server Primary 2 192.168.30.52 192.168.30.52 2 /gaussdb/cluster/data/cm/cm_server Standby 3 192.168.30.53 192.168.30.53 3 /gaussdb/cluster/data/cm/cm_server Standby[ ETCD State ]node node_ip instance state1 192.168.30.51 192.168.30.51 7001 /gaussdb/cluster/data/etcd StateFollower 2 192.168.30.52 192.168.30.52 7002 /gaussdb/cluster/data/etcd StateFollower 3 192.168.30.53 192.168.30.53 7003 /gaussdb/cluster/data/etcd StateLeader[ Cluster State ]cluster_state : Normal redistributing : No balanced : No current_az : AZ_ALL[ Coordinator State ]node node_ip instance state1 192.168.30.51 192.168.30.51 5001 8000 /gaussdb/cluster/data/cn Normal 2 192.168.30.52 192.168.30.52 5002 8000 /gaussdb/cluster/data/cn Normal 3 192.168.30.53 192.168.30.53 5003 8000 /gaussdb/cluster/data/cn Normal[ Central Coordinator State ]node node_ip instance state2 192.168.30.52 192.168.30.52 5002 /gaussdb/cluster/data/cn Normal[ GTM State ]node node_ip instance state sync_state1 192.168.30.51 192.168.30.51 1001 /gaussdb/cluster/data/gtm P Primary Connection ok Sync 2 192.168.30.52 192.168.30.52 1002 /gaussdb/cluster/data/gtm S Standby Connection ok Sync 3 192.168.30.53 192.168.30.53 1003 /gaussdb/cluster/data/gtm S Standby Connection ok Sync[ Datanode State ]node node_ip instance state | node node_ip instance state | node node_ip instancestate1 192.168.30.51 192.168.30.51 6001 33100 /gaussdb/cluster/data/dn/dn_6001 P Primary Normal | 2 192.168.30.52 192.168.30.52 6002 33100 /gaussdb/cluster/data/dn/dn_6002 S Standby Normal | 3 192.168.30.53 192.168.30.53 6003 33100 /gaussdb/cluster/data/dn/dn_6003S Standby Normal 2 192.168.30.52 192.168.30.52 6004 33120 /gaussdb/cluster/data/dn/dn_6004 P Standby Normal | 1 192.168.30.51 192.168.30.51 6005 33120 /gaussdb/cluster/data/dn/dn_6005 S Primary Normal | 3 192.168.30.53 192.168.30.53 6006 33120 /gaussdb/cluster/data/dn/dn_6006S Standby Normal 3 192.168.30.53 192.168.30.53 6007 33140 /gaussdb/cluster/data/dn/dn_6007 P Primary Normal | 2 192.168.30.52 192.168.30.52 6008 33140 /gaussdb/cluster/data/dn/dn_6008 S Standby Normal | 1 192.168.30.51 192.168.30.51 6009 33140 /gaussdb/cluster/data/dn/dn_6009S Standby Normal [omm@node01 ~]$

高弹性 在弹性扩展方面，GaussDB采用计算-内存-存储三层池化解耦设计，支持分层独立弹性伸缩，对应用透明。计算层将全局锁和页面属主目录（POD，Page Owner Directory）等状态下沉至共享内存层，本地仅保留数据页面，计算层增删节点无需状态信息迁移，实现秒级弹性伸缩；共享内存层采用POD方式管理缓冲池页面属主关系，POD基于一致性Hash均匀分布在共享内存层，增删节点仅迁移少量Bucket，内存层秒级弹性，应用无感知。GaussDB云原生数据库，打造计算/内存/存储三层池化架构，实现多节点透明多写、分层弹性伸缩、秒级快速恢复、秒级节点扩展能力，为用户带来最大价值。GaussDB持续创新，打造新型竞争力，为世界提供更优选择。

高可用 在高可用方面，GaussDB云原生数据库的节点故障能够做到6s内恢复，且对其他正常节点无影响，而其它厂商需要30s以上。可用性存在上述差异的根本原因在于，该云厂商部署在共享内存层支撑多写的核心组件存在单点问题，保存其上的全量脏页面、锁、事务状态等信息，在故障时需要全量恢复，特别是全局Buffer Pool，需要从共享存储的检查点依次恢复，较为耗时。与之相对比，GaussDB云原生围绕高可用做了大量创新： 首先，共享内存无脏页状态设计，仅内存节点故障时无需恢复WAL；其次，计算节点采用Past-Image设计，计算节点故障可从最近Image恢复，恢复时间大幅减少； 最后，GaussDB云原生业界首创双check-point设计，计算节点故障从内存检查点恢复，只有计算节点和共享内存节点同时故障时，才从共享存储的检查点恢复WAL。

高性能以D和O为代表的传统shared-disk多主架构，支持多节点透明多写，具备一定的吞吐扩展能力，在很长一段时间成功的支撑了企业关键业务负载。但其限制也很明显，首先D和O多写架构依赖专有硬件，弹性伸缩能力差，TCO较高，用户易被Lock in，在云计算和通用服务器大行其道的背景下，越来越多的用户希望多写架构能够运行于开放平台之上。另外，D和O的多节点并发事务状态多采用中心化模式设计，导致其扩展线性比较低，在重业务负载情况下，资源的扩展并不能带来对等的性能收益，导致其业务承载能力受到限制。 为继承D和O透明多写能力，同时充分利用云平台资源弹性和RDMA高速网络等先进硬件技术，当前业界头部数据库厂商均积极研究云原生多写架构。近期，某云厂商推出的云原生多主数据库，采用计算-内存-存储三层解耦的云原生架构设计，基于中心化组件实现多节点透明多写，是该方向架构演进的一个突破。但从其发表论文的测试数据来看，32节点TPCC吞吐为910万tpmC，而华为GaussDB云原生数据库在相同32节点可达3000+万tpmC的吞吐能力，支持128节点（16384鲲鹏核心）部署，能够支撑PB级OLTP业务规模，目前已在华为内部支撑实际业务生产。 存在上述性能差距的原因，笔者认为有如下几点： 第一，国内云厂商多写数据库的页面跨节点修改，采用进程级LLSN实现WAL记录的保序，而GaussDB云原生数据库采用细粒度页面级Lamport LSN保序，进程内无全局冲突点，在多核/众核环境下扩展性更强，能够更好的发挥硬件算力。第二，GaussDB云原生采用页面亲和性设计，脏页面无需回写共享内存，而该云厂商数据库采用中心式全量脏页面管理机制，事务产生的脏页面均须回写共享内存，造成大量页面在网络间频繁传递。GaussDB云原生数据库架构图 GaussDB云原生数据库在节点亲和性算法设计方面，除了分布式缓冲池的页面属主和读授权机制外，Undo段和FSM算法也充分考虑了节点亲和性设计，将节点间的网络交互降至最低，确保极致性能。 在Undo segment的节点亲和性设计上，从undo tablespace分配空间，多节点共享undo tablespace，而每个计算节点使用分布式锁机制亲和性分配Undo segment，每个Undo segment同一时刻只能被一个计算节点绑定。Undo segment亲和性分配机制图 在FSM空闲空间管理节点亲和性算法上，针对Heap FSM采用自动分区机制优化表数据插入分配页面算法，减少节点间冲突；针对索引空页面管理，采用自动分区机制优化索引查找空页面算法，减少节点间冲突。

  一、前言 在数据库中构建动态SQL语句是指根据不同的条件或参数创建不同的SQL语句。这通常是为了适应不同的业务需求，提高SQL的灵活性和效率。GaussDB数据库是一款具备高性能、高可用性和高扩展性的关系型数据库，它提供了丰富的功能和工具，支持动态SQL语句的构建。下面我们将介绍如何使用GaussDB数据库构建动态SQL语句。  二、构建动态SQL语句的基本步骤和注意事项 1、基本步骤  分析需求：首先需要明确业务需求，了解需要执行哪些SQL查询操作，并根据需求的不同来动态构建SQL语句。 准备参数：根据查询操作的不同，准备相应的参数，如筛选条件、排序规则等。 SQL拼接：根据需求和参数，使用字符串拼接方式构建SQL语句。 执行查询：使用GaussDB数据库的查询接口，执行构建好的SQL语句并获取查询结果。 处理结果：将查询结果进行处理和展示，可以是前端页面或后端接口等形式。 2、主要事项 避免SQL注入：在拼接SQL语句时，务必注意避免SQL注入的风险，不要直接拼接用户输入的内容。 性能优化：对于大规模数据的查询操作，需要进行性能优化，如使用索引、分页查询等方式来提高查询效率。 事务处理：如果涉及事务处理，需要使用GaussDB数据库的事务管理功能来确保数据的一致性和可靠性。 安全性保障：对于敏感数据的查询操作，需要进行安全性保障，如数据脱敏、权限控制等方式来保护数据的安全。 三、GaussDB中执行动态查询语句（示例） GaussDB提供两种方式：使用EXECUTE IMMEDIATE、OPEN FOR实现动态查询。前者通过动态执行SELECT语句，后者结合了游标的使用。当需要将查询的结果保存在一个数据集用于提取时，可使用OPEN FOR实现动态查询。  1、方式一：EXECUTE IMMEDIATE  ``` --传递并检索值（INTO子句用在USING子句前）： CREATE OR REPLACE FUNCTION dynamic_f() RETURNS text LANGUAGE plpgsql AS $$ DECLARE     d_id       INT := 2;    d_name     VARCHAR(20);    d_salary   INT; BEGIN    EXECUTE IMMEDIATE 'SELECT name,salary FROM company1 WHERE id = :1' INTO d_name,d_salary USING IN d_id;      RETURN '姓名:' || d_name || ' , 薪水:￥' ||d_salary; END $$;  --执行 CALL dynamic_f(); ```  主要属性说明：  INTO的变量 ：用于指定存放单行查询结果的变量。 USING IN的变量： 用于指定存放传递给动态SQL值的变量，在SQL拼接时可用占位符，占位符命名以“:”开始，后面可跟数字、字符或字符串，与USING子句的变量一一对应。 执行结果：   2、方式二：OPEN FOR  ``` --使用OPEN FOR打开动态游标来执行 CREATE OR REPLACE FUNCTION dynamic_cur() RETURNS text LANGUAGE plpgsql AS $$ DECLARE     v_name          VARCHAR2(20);     v_salary        INT;          TYPE ref_type IS REF CURSOR;  --定义游标类型     my_cur ref_type;              --定义游标变量      BEGIN     OPEN my_cur FOR 'SELECT name,salary FROM company1 WHERE id = :1' USING '3';   --打开游标, using是可选的     FETCH my_cur INTO v_name, v_salary; --获取数据     WHILE my_cur%FOUND          LOOP         RETURN v_name||'#'||v_salary;         FETCH my_cur INTO v_name, v_salary;     END LOOP;     CLOSE my_cur;   --关闭游标 END $$;  --执行 CALL dynamic_cur(); ```  主要属性说明  'WHILE my_cur%FOUND'： 是一个循环控制语句。'my_cur'是一个游标，而'%FOUND'是游标状态。当游标找到符合条件的记录时，这个状态就会为真（也就是说，如果'my_cur%'FOUND为真，那么就继续执行循环中的代码）。当游标没有更多的记录可返回时（或者达到了游标返回的最大记录数），这个状态就会为假，然后循环就会停止。所以，'WHILE my_cur%FOUND'的意思是：当游标'my_cur'还有记录可返回时，就继续执行循环中的代码。  执行结果   四、GaussDB中的动态非查询语句（示例） 其实这个可以简单的理解为非“SELECT语句”，基本写法跟前面的示例类似，下面继续以company1表为例：  ``` --使用EXECUTE IMMEDIATE执行动态非查询语句 CREATE OR REPLACE FUNCTION dynamic_cur() RETURNS void LANGUAGE plpgsql AS $$ DECLARE     v_id       INT := 4;     v_name     VARCHAR2(10) := 'ZhangSan';     v_age      INT := 30;      v_address  VARCHAR2(10) := 'BeiJing';     v_salary   INT := 30000;      v_newname   VARCHAR2(10) := 'company4'; BEGIN      EXECUTE IMMEDIATE 'INSERT INTO company1 VALUES(:1, :2, :3, :4, :5)' USING v_id, v_name, v_age,v_address,v_salary;      EXECUTE IMMEDIATE 'ALTER TABLE company1 RENAME to ' || v_newname;          END $$;  --执行 CALL dynamic_cur();  --查看结果 SELECT * FROM company4; 执行结果 ```   五、小结 通过使用GaussDB数据库构建动态SQL语句，数据应用部门可以更好地应对不断变化的数据查询需求，提高应用程序的性能和可维护性。本文主要介绍了如何使用GaussDB数据库构建动态SQL语句的基本步骤和注意事项，并通过实际案例进行了演示，欢迎大家测试、交流。  ——结束  ​ 

  一、前言 GaussDB是一款高性能、高可用的分布式数据库，广泛应用于各类行业和场景。在GaussDB中，锁是实现并发控制的关键机制之一，用于协调多个事务之间的数据访问，确保数据的一致性和完整性。本文将围绕GaussDB数据库的LOCK TABLE 做一简单介绍。  二、GaussDB数据库的锁 GaussDB提供了多种锁模式用于控制对表中数据的并发访问。这些模式可以用在MVCC（多版本并发控制）无法给出期望行为的场合。同样，大多数GaussDB命令自动施加恰当的锁，以保证被引用的表在命令的执行过程中不会以一种不兼容的方式被删除或者修改。比如，在存在其他并发操作的时候，ALTER TABLE是不能在同一个表上执行的。  1、GaussDB中的LOCK TABLE LOCK TABLE获取表级锁。  如果需要保持数据库数据的一致性，可以使用LOCK TABLE来阻止其他用户修改表。例如，一个应用需要保证表中的数据在事务的运行过程中不被修改。为实现这个目的，则可以对表进行锁定，这样将防止数据不被并发修改。LOCK TABLE只在一个事务块的内部有用，在事务结束时就会被释放。  1）语法格式  ``` LOCK [ TABLE ] name  IN {ACCESS SHARE | ROW SHARE | ROW EXCLUSIVE | SHARE UPDATE EXCLUSIVE | SHARE | SHARE ROW EXCLUSIVE | EXCLUSIVE | ACCESS EXCLUSIVE} MODE ```  2）参数说明  1）name：要锁定的表的名称。  2）锁的模式：  ACCESS SHARE：只读取表而不修改。所有对表进行读取而不修改的SQL语句都会自动请求这种锁。 ROW SHARE：允许对表进行并发读取，禁止对表进行其他操作。SELECT FOR UPDATE和SELECT FOR SHARE命令会自动在目标表上请求ROW SHARE锁（且所有被引用但不是FOR SHARE/FOR UPDATE的其他表上，还会自动加上ACCESS SHARE锁）。对于分区表，SELECT FOR SHARE操作还会在DN上获取partition对象的ROW EXCLUSIVE锁进行并发控制。 ROW EXCLUSIVE：与ROW SHARE锁相同，ROW EXCLUSIVE允许并发读取表，但是禁止修改表中数据。UPDATE，DELETE，INSERT命令会自动在目标表上请求这个锁（且所有被引用的其他表上还会自动加上的ACCESS SHARE锁）。通常情况下，所有会修改表数据的命令都会请求表的ROW EXCLUSIVE锁。 SHARE UPDATE EXCLUSIVE：保护一个表的模式不被并发修改，以及禁止在目标表上执行垃圾回收命令（VACUUM）。VACUUM（不带FULL选项）、ANALYZE、CREATE INDEX CONCURRENTLY命令会自动请求这样的锁。 SHARE：允许并发的查询，但是禁止对表进行修改。CREATE INDEX（不带CONCURRENTLY）语句会自动请求这种锁。 EXCLUSIVE:允许对目标表进行并发查询，但是禁止任何其他操作。这个模式只允许并发加ACCESS SHARE锁，也就是说，只有对表的读动作可以和持有这个锁模式的事务并发执行。任何SQL语句都不会在用户表上自动请求这个锁模式。然而在某些操作的时候，会在某些系统表上请求它。 SHARE ROW EXCLUSIVE:禁止对表进行任何的并发修改，而且是独占锁，因此一个会话中只能获取一次。任何SQL语句都不会自动请求这个锁模式。 ACCESS EXCLUSIVE:保证其所有者（事务）是可以访问该表的唯一事务。ALTER TABLE，DROP TABLE，TRUNCATE，REINDEX，CLUSTER，VACUUM FULL命令会自动请求这种锁。在LOCK TABLE命令没有明确声明需要的锁模式时，它是缺省锁模式。 2、示例一：ACCESS EXCLUSIVE 模式  ``` --创建测试表 DROP TABLE IF EXISTS omm2.company; CREATE TABLE omm2.company(    id int4 PRIMARY key NOT NULL   ,name varchar(10) NOT NULL   ,age int4 NOT NULL   ,address varchar(20) NOT NULL   ,salary float4 NOT NULL );  --初始化数据 INSERT INTO omm2.company VALUES (1, 'Paul', 32, 'California', 20000); INSERT INTO omm2.company VALUES (2, 'Allen', 25, 'Texas', 15000); INSERT INTO omm2.company VALUES (3, 'Teddy', 23, 'Norway', 20000); INSERT INTO omm2.company VALUES (4, 'ZhangSan', 30, 'BeiJing', 30000);  --启动一个事务 START TRANSACTION; LOCK TABLE omm2.company IN ACCESS EXCLUSIVE MODE; DELETE FROM omm2.company WHERE name ='Allen'; COMMIT; ```  解析：  “START TRANSACTION;”：启动一个新的事务。在数据库中，事务是一组一起执行的SQL语句，要么全部成功，要么全部失败。这确保了数据的一致性。 “LOCK TABLE omm2.company IN ACCESS EXCLUSIVE MODE;”：对omm2.company表进行了排他性锁定。在此模式下，其他会话不能对表进行读写操作，直到这个事务结束。这样可以防止在删除操作过程中其他事务对表产生干扰。 “DELETE FROM omm2.company WHERE name ='Allen'; ”：从omm2.company表中删除了所有名为'Allen'的记录。 “COMMIT;”：这行代码提交了前面的事务。在事务中执行的任何更改（在本例中是删除操作）在提交后才会永久保存在数据库中。 总的来说，这段代码删除了名为'Allen'的所有记录，并确保这个操作在提交之前不会被其他事务干扰。  3、示例二：SHARE ROW EXCLUSIVE 模式  ``` --复用示例一的测试表 CREATE TABLE omm2.company1 AS TABLE omm2.company;  --启动一个事务 START TRANSACTION; LOCK TABLE omm2.company1 IN SHARE ROW EXCLUSIVE MODE; DELETE FROM omm2.company1 WHERE name ='Allen'; COMMIT; ```  解析：  “CREATE TABLE omm2.company1 AS TABLE omm2.company;”：创建了一个新的表omm2.company1，其结构复制自已有的表omm2.company。这种操作通常用于创建表的副本，或者为某个操作创建一个临时的、与原表结构相同的新表。 “START TRANSACTION; ”：启动一个新的事务。在数据库中，事务是一组一起执行的SQL语句，要么全部成功，要么全部失败，这可以确保数据的一致性。 “LOCK TABLE omm2.company1 IN SHARE ROW EXCLUSIVE MODE; ”：对表omm2.company1进行了排他性锁定。在这种模式下，其他会话不能对表进行读写操作，直到这个事务结束，这样可以防止在删除操作过程中其他事务对表产生干扰。 “DELETE FROM omm2.company1 WHERE name ='Allen';”：从表omm1.company1中删除了所有名为'Allen'的记录。 “COMMIT;”:提交前面的事务。在事务中执行的任何更改（在本例中是删除操作）在提交后才会永久保存在数据库中。 三、小结 GaussDB数据库的锁机制是其重要的组成部分，用于支持并发控制和事务隔离。GaussDB实现了不同级别的事务隔离和并发控制，满足了不同场景下的需求。当然了，使用GaussDB数据库时也需要注意一些问题，如锁的管理和数据库的规划等。合理的锁管理和数据库规划能够提高系统的性能和可用性，反之则可能导致数据一致性问题或者系统故障。  ——结束  ​